Direct 4.01b Upgrade Necessities

[AlphaWolf]

Here are the files necessary for upgrading your S2 tivo from any SW version up to 4.01b. Using these you can do a direct upgrade without downloading a whole disk image and without losing your tivos thumbs, season passes, recordings, etc.

Both the loopsets and the 4.01b slices can be found here.

A stock (virgin, as in no killhdinitrd) 3.1.1c kernel and a stock 3.1.5 dssappAV (required for RID units) can be found here.

If you use these links verbatim with emule (not edonkey2000) theres not even a one in 100 trillion chance of corruption or downloading a fake file. But should these files end up on other p2p networks, here are the sha1sums of the files:

b996a6fec4d24c4e1e5048e971d2c0db6e5db3f9  TiVo.4.01bslices.and.loopsets.AlphaWolf.tar.bz2
333aa38fed2fdbcf16befb5713d616db2a2b7411  TiVo.Stock.311Ckernel.and.315dssappAV.AlphaWolf.tar.bz2

Before proceeding with this process, you should probably familiarize yourself with the material contained in this thread (you can ignore the monte bits though.) For those of you who used a 'sleeper iso' on your tivo, you should search for information about renormalizing your tivos boot process.

If you do it right you wont have to remove your hard disk from your tivo either. Heres a basic rundown of what you need to do (note these instructions are not exact and may be wrong, they just give you a general idea of what to do:)

'dbload' all of the slices contained in the first bzip2 archive, then remove the 'reboot' command from /tvbin/installSw.itcl (replace it with an exit command or something, you don't want your tivo to reboot when it finishes) then run it as follows:

/tvbin/installSw.itcl 4.0.1b-01-2-240

After it finishes, mount your new root partition, and copy over all of your necessities, e.g. /tivo-bin, /tivoweb-tcl, /hack, /etc/rc.d/rc.sysinit.author, etc.

If you are using a UMA6 or RID tivo, grab the second bzip2 archive and replace the /tvbin/dssapp in your new root with the one provided in the archive.

If you need to chainload your kernel, run killhdinitrd on the provided vmlinux.px image, initialize your kernel partition and dd the 3.1.1c kernel image provided over to it (if unsure, do it to both kernel partitions.)

killhdinitrd vmlinux.px
dd if=/dev/zero of=/dev/hda3
dd if=vmlinux.px of=/dev/hda3

Or /dev/hda6, whichever you are on.

After that, go to this thread and download and apply the following files to your new root as per the instructions in that thread: lba48_2.4.18.rar, init_framework.tgz, and uma6fix_0.9.0.tgz.

[compwiz312]

Alphawolf, two questions I have to ask:

1) Is the dssappAV necessary? I have seen no mention of it anywhere else involving 4.0 RID (it is certainly possible that I missed it). Also, if it is from version 3.1.5, would it be compatible with 4.x (different kernel versions). Finally, if it is necessary, are there any modifications that need to be done to it or should we just place it in the /tvbin directory.

2) Would you mind sharing how you extracted the loopsets? I tried doing this once with ADH's script, but all I received were errors.

Thanks in advance,
Justin

[AlphaWolf]

Originally Posted by compwiz312

1) Is the dssappAV necessary? I have seen no mention of it anywhere else involving 4.0 RID (it is certainly possible that I missed it). Also, if it is from version 3.1.5, would it be compatible with 4.x (different kernel versions). Finally, if it is necessary, are there any modifications that need to be done to it or should we just place it in the /tvbin directory.

Yes, that is the same 'dssapp' that is being distributed in the current 4.x on RID thread. You will need that if your RID receiver is strong paired with your access card, because the regular dssapp doesn't have the AV or "Advanced Verification" mechanisms that are required for a strong paired access card configuration. 4.X doesn't provide dssappAV, so we have to replace dssapp with a compatible dssappAV counterpart from 3.1.5.

That one is probably illegal to be distributed on DDB though. The reason I provided that archive with both the kernel and the dssappAV is that emule will provide a more permanent home for the two if tivo ever brings down the FTP containing the kernels and/or requires DDB to remove that dssapp binary from the 4.x on RID files thread. Tivo and/or Directv can do it if they are so inclined.

Originally Posted by compwiz312

2) Would you mind sharing how you extracted the loopsets? I tried doing this once with ADH's script, but all I received were errors.

I didn't.

[compwiz312]

Based on your previous message, I infer that if we replace dssapp with the one from the 4.x RID thread, then we don't need the dssappAV you provide or am I wrong on that note?

Second, if you didn't extract the loopsets, would you mind sharing who did, because I would really like to figure out how to do this and I am stumped with ADH's script (I am trying to make 3.x images that could be restored on <40GB drives for some of my test units).

TIA

[AlphaWolf]

Originally Posted by compwiz312

Based on your previous message, I infer that if we replace dssapp with the one from the 4.x RID thread, then we don't need the dssappAV you provide

Yep

Originally Posted by compwiz312

Second, if you didn't extract the loopsets, would you mind sharing who did, because I would really like to figure out how to do this and I am stumped with ADH's script (I am trying to make 3.x images that could be restored on <40GB drives for some of my test units).

Sorry, I'll have to let him speak on that one, if he is so inclined.

[erhan]

As an additional benefit, people can use the same slices to upgrade non-RID S2s without having to do any chain loading.

Run installSw.itcl as per AW's instructions above, copy over the hacks and and killhdinitrd the kernel in the new root partition. You should be all set, I think.

I've been meaning to upgrade my 4.0 to 4.01 and get rid of the monte stuff, but didn't feel like pulling the drive to do mfsrestores. This is a big help, thanks AlphaWolf.

[malfunct]

Originally Posted by erhan

As an additional benefit, people can use the same slices to upgrade non-RID S2s without having to do any chain loading.

Run installSw.itcl as per AW's instructions above, copy over the hacks and and killhdinitrd the kernel in the new root partition. You should be all set, I think.

I've been meaning to upgrade my 4.0 to 4.01 and get rid of the monte stuff, but didn't feel like pulling the drive to do mfsrestores. This is a big help, thanks AlphaWolf.

Nope, even with killhdinitrd I think that the 4.0 kernel will fail the prom signature check since the kernel is the wrong one for that machine.

[compwiz312]

Originally Posted by malfunct

Nope, even with killhdinitrd I think that the 4.0 kernel will fail the prom signature check since the kernel is the wrong one for that machine.

AFAIK, all kernels designed for Series 2 boxes (not Series 2.5 units) will boot on any Series 2 (not 2.5) device , whether it is SA or DTV.

That includes

3.1.u5* **
3.1.1(b/c/d/e) **
3.1.5(e)
4.0(.1b)*
5.x (ones for Pioneer or Toshiba units, not Humax or S2.5 units)

*Requires contigmem=19m to display properly on boot and will not boot a uma6 (RID DTivo) without using monte.
**Will not boot a HR10-250 HD DirecTivo

[malfunct]

Originally Posted by compwiz312

AFAIK, all kernels designed for Series 2 boxes (not Series 2.5 units) will boot on any Series 2 device, whether it is SA or DTV.

That includes

3.1.u5
3.1.1(b/c/d/e)
3.1.5(e)
4.0(.1b)
5.x (ones for Pioneer or Toshiba units, not Humax or S2.5 units)

Interesting, thats good to know. Makes me wonder why people seem to say you have to monte to have 4.0 on dtivo.

[alldeadhomiez]

Originally Posted by compwiz312

AFAIK, all kernels designed for Series 2 boxes (not Series 2.5 units) will boot on any Series 2 device, whether it is SA or DTV.

That includes

3.1.u5
3.1.1(b/c/d/e)
3.1.5(e)
4.0(.1b)
5.x (ones for Pioneer or Toshiba units, not Humax or S2.5 units)

Booting issues that I am aware of:

HR10-250 won't boot the 3.1.U5/2.4.4 kernel, possibly others

Uma6 DTiVo will boot 3.1.U5/3.1.0/4.x kernels, but the memory configuration will be broken. This means that you will probably get green goo on the startup screen, and you will need to monte into a compatible kernel to actually run the TiVo software.

Series2.0 and Series2.5 kernels can never be mixed or matched, because the chipset initialization code (and a few other things) is completely different. Also, all Series2.5 boxes require the "TCD1" header; no current Series2.0 boxes do, so they ignore it if present.

[compwiz312]

Originally Posted by alldeadhomiez

Booting issues that I am aware of {cut}

Edited my message to make is a little clearer...

[AhoyMatey]

Originally Posted by malfunct

Interesting, thats good to know. Makes me wonder why people seem to say you have to monte to have 4.0 on dtivo.

The only reason (and it's been stated elsewhere) is to load a custom kernel.

I have an hdvr2 using a killhdinitrd'd 4.01a kernel with 4.01b running. Of course, that's soon to change as I upgrade to a 200GB harddrive and require LBA48 support...

[bnm81002]

I just tried to enter those links and it won't show up? it's only 10:20PM in NY now?

[tivomaster]

Bummer I missed them too...
That is what I get for going to my families for thanksgiving

[AlphaWolf]

I don't know what you guys are talking about, its still up. Also there have been 44 completed downloads throughout the day, so there should be more sources than just myself, even after I bring it offline.