Toshiba SD-H400 hard drive expansion - Support Thread

[davedonohue]

Originally Posted by Jamie

Nope, you didn't miss it. I'm not changing those. The 5.1.1b software didn't seem to care, but as we've seen elsewhere, other software versions might.

I can alter it to change those too. What should I use for defaults? min 40G max 1TB?

Jamie, speaking of the 5.1.1b, do you know of any forum where the technically minded are discovering whether your excellent mod to the Toshiba is affected by the rollout of 7.1? As eager as I am to get TiVoToGo, I'd hate to think of what might happen as I'm well over the original space allocation, though hardly approaching the limits of my 300GB drive.

If people are seeing conflicts, I'll gladly act as a guinea pig again as I'll certainly be affected ad will likely try to avoid the upgrade if possible.

Thanks in advance!

[Jamie]

Originally Posted by davedonohue

Jamie, speaking of the 5.1.1b, do you know of any forum where the technically minded are discovering whether your excellent mod to the Toshiba is affected by the rollout of 7.1? As eager as I am to get TiVoToGo, I'd hate to think of what might happen as I'm well over the original space allocation, though hardly approaching the limits of my 300GB drive.

If people are seeing conflicts, I'll gladly act as a guinea pig again as I'll certainly be affected ad will likely try to avoid the upgrade if possible.

I haven't heard anything. I put myself on the priority list for the update so I could take a look. I'm not expecting the update to cause any problems, but one never knows.

On my own machine I did the "RubbishObjectByFsid" method that completely deletes the Active DiskConfiguration. Once I get the update I can test both methods with 7.1.

Sorry I can't give you anything more definitive than that.

[alldeadhomiez]

Speaking of guinea pigs, it looks like some of the "drive upgrade" vendors have provided us with a few thousand of them.

http://www.tivocommunity.com/tivo-vb...47#post2501247

Current download stats as of 2005/01/08:

sd-h400_unlock_user.zip (246.4 KB, 73 views)
sd-h400_unlock_devl.zip (348.2 KB, 86 views)

This will get interesting...

[Jamie]

Originally Posted by alldeadhomiez

Speaking of guinea pigs, it looks like some of the "drive upgrade" vendors have provided us with a few thousand of them. http://www.tivocommunity.com/tivo-vb...47#post2501247
...

Yikes! Is there any evidence the user referenced in that thread used the sd-h400_unlock utility? I'll try to test on a sd-h400 upgraded to 7.1 as soon as I'm able.

{edit: Maybe your point was that all drive expansions may now be exposed to some kind of 7.1 capacity lock. That will be interesting if it turns out to be true.}

[ronnythunder]

Originally Posted by Jamie

{edit: Maybe your point was that all drive expansions may now be exposed to some kind of 7.1 capacity lock. That will be interesting if it turns out to be true.}

yes, i imagine things would heat up over here if this was the case.

ronny

[Jamie]

I did a little testing with 7.1 on the Toshiba sd-h400 today. I took a virgin 5.1.1b 80 hour image, upgraded it to 7.1 via slices, and it reported 83 hours. I then expanded it to fill the disk it was on (200GB), and it still reported 83 hours. Finally, I ran the sd-h400_unlock utility, and that cracked the lock and it then reports 253 hours. This tells me 7.1 on the sd-h400 still has the capacity lock, and the sd-h400_unlock utility can still remove it.

There's more to be tested, but that's about all I have time for today. I'm interested in what happens to an unlocked unit when it goes through an upgrade, and am interested in what happens to units where the Active object was rubbished instead of modified. I'll do these tests another day.

[ronnythunder]

sounds like the next test might be:

restore 5.1.1 image
expand and run unlock util
verify space (optional)
upgrade via slices
verify space
re-run unlock
verify space

did you get a look at the diskconfigurations/active before you ran the unlock util after upgrading to 7.1?

ronny

[Jamie]

Originally Posted by ronnythunder

did you get a look at the diskconfigurations/active before you ran the unlock util after upgrading to 7.1?

Yes. No change over the original contents.

[ronnythunder]

so, doesn't that mean that the unlock util shouldn't have had any effect?

ronny

[Jamie]

Originally Posted by ronnythunder

so, doesn't that mean that the unlock util shouldn't have had any effect?

no. I must have been unclear about something.

I took an original stock disk that had the stock Active DiskConfiguration and upgraded it with slices to 7.1. Of course I had to do a minimal amount of hacking to be able to get a serial bash to upgrade via slices, but I did only the minimum necessary for that (installed a 3.1.5 killhdinitrd kernel, AIO utilities, and started serial bash from test.conf). The Active DiskConfiguration object wasn't affected by the upgrade, and it appears that the 7.1 software still uses it. After that I ran the unlock utility, specifing a small "Clips" allocation. The 7.1 software respected the changes and increased the reported "hours" capacity.

One thing that seemed a little odd was that the capacity while the locked Active disk configuration was still in place was reported as 83 hours rather than 80. Maybe the ratio of GB's to hours has changed slightly.

[Jamie]

I did another round of 7.1 testing on an sd-h400. This time I expanded and unlocked first (with sd-h400_unlock), then upgraded to 7.1. Everything looked fine. The 7.1 upgrade didn't cause any problems with the unlocked drive.

[SiREoNe]

So Jaime, what you're saying is if I have 5.1b then expanded to say 300GB then unlock, add a few hacks (sleeper) then I shouldn't have any problems getting 7.1?

[Jamie]

Originally Posted by SiREoNe

So Jaime, what you're saying is if I have 5.1b then expanded to say 300GB then unlock, add a few hacks (sleeper) then I shouldn't have any problems getting 7.1?

My belief is that an unlocked drive should persist through the upgrade. I tested by upgrading by hand via slices rather than receiving an upgrade from Tivo, so it's always possible your mileage may vary.

Hacks are another matter entirely. You'll definitely need to reinstall your hacks in the new root partition and install a killhdinitrd'd kernel in the new kernel partition. And I have no idea how an upgrade might interact with the tivoscripts old-style monte partition layout (decoy roots, and all that).

[SiREoNe]

Well, good news and bad news....The Good news is, I was able to upgrade to 7.1 and retain my HD size. I had several 'Pending Restarts' but the system would not upgrade. I had to go to bash via telnet and issue:

echo mls /SwSystem | tivosh

To get the new version, then:

installSw.itcl 7.1-01-2-264

To install the new version. Then Bad news is, no more Telnet and I guess other hacks. What's the easiest way to get these back? I don't wanna use Tivoscripts on 7.1?

[Jamie]

Originally Posted by SiREoNe

What's the easiest way to get these back? I don't wanna use Tivoscripts on 7.1?

tivoscripts is deprecated and is unlikely to work with 7.1. In fact, most hacks aren't ready to work with 7.1 yet. You'll want to install a killhdinitrd kernel (the 3.1.5 kernel will work) to get around the tivo security checks. See this thread for other 7.1 troubleshooting information. In particular, you'll need to pay attention to the iptables replacement ADH recommends there. Once you get that far you should be able to get telnet and ftp access going.