killhdinitrd 0.9.x Support Thread

[djsinc99]

I haven't yet tried 3.1.5. This unit has never been hacked and I have a new drive on order that I plan to do expansion and hacks on. I'm waiting to pull my drive until the new one arrives. I'm surprised to hear the 3.1.5 kernel didn't work for you, it was my understanding that its been working in all 7.x versions so far.

I will get back when I have some results to report.

[puk]

Sorry I was not more specific. This is the current kernel info:

7.2.2-oth-K1
Linux version 2.4.20 (build@buildmaster50)
(gcc version 3.3.4) #1 Tue Feb 14 20:57:16 PST 2006

I don't have a binary on the boot CD to generate an MD5 checksum, but I will try to get it. I suspect the checksum will be different than the one published for ver 0.9.3.

Is it possible that since I have a HUMAX DRT400 with DVD (SN 595...) the kernel is slightly different from the ones that killhdinitrd works with?

George

Just to add my experience to the pile... I didn't write down my TiVo version; it was not 7.2.2-oth-K1, but 7.2.2-some-longer-string. BUT doing a strings on my boot partition gives me:

Linux version 2.4.20 (build@buildmaster50) (gcc version 3.3.4) #1 Tue Feb 14 20:55:02 PST 2006

which is the same same datestamp that the readme says is supported by 0.9.3. Nonetheless, I guess it is different (I also don't have a boot disk with md5/md5sum installed), since I also get "no exploit found for this kernel." Hopefully someone will release a compatible kernel image (I'd rather stick to one closer to the "default" than the 3.1.5 image), or update the source to support this one; perhaps I will when I have some hours to kill.

-puk

[djsinc99]

My upgrade drive arrived, so here's a description of my results as promised.
I had an unhacked S2 SA TCD240 unit that had recently updated to OS version 7.2.2-oth.01-2-140.

Pulled the original drive and backed it up using mfstools.

Restored and expanded the backup to my new upgrade drive.

Installed new drive in Tivo and verified new size and that networking was still functioning.

Pulled drive again and proceeded to modify bootpage, and copy in killhdinitrd'd 3.1.5 kernel from PTVupgrade CD.

Copied on tivotools, and created the rc.sysinit.author file to setup telnet, ftp, bash. Also moved netfilter firewall out of the way.

Put the drive back in the tivo and it was stuck in a reboot loop.

Pulled the drive again and after some reading, realized that I needed to modify the iptables file.

Put the drive back in the tivo and it booted up! DHCP didn't work as I expected so I assigned a static IP address. At first it didn't work because I assigned it 192.168.0.255. Looking into the router config, I saw that the DHCP address range was from 192.168.0.2 to 192.168.0.51. So I changed the address I assigned the tivo to 50 instead. booyah! I could telnet and ftp into the box.

ftp'd the patched superpatch, ran it, reboot, and i can now do mrv transfers with my directivo. woohoo!

[7.1]

Hopefully someone will release a compatible kernel image (I'd rather stick to one closer to the "default" than the 3.1.5 image), or update the source to support this one; perhaps I will when I have some hours to kill.

The latest PTupgrade LBA48 CD "with enhancements" includes the 7.2.2-oth.K1 kernel, with killhdinitrd 0.9.3 already run on it. It's labelled version 4.03. I recommend this kernel for those running 7.x, especially on 140 hardware that otherwise must be monte'd.

The 7.2.2-oth.K1-01-2 kernel proper is identical to the one from 7.2.2-oth.01-2. The initrd's are different, and 7.2.2-oth.01-2 doesn't seem to have a suitable jump point in the initrd, so I don't expect it will be supported.

[ScanMan]

Is there any significant difference b/w:

booting from killhdinitrd 3.1.5 kernel into 7.2.2-oth.01-2 s/w

vs.

booting from killhdinitrd 7.2.2-oth.K1 kernel into 7.2.2-oth.01-2 s/w

[PlainBill]

Is there any significant difference b/w:

booting from killhdinitrd 3.1.5 kernel into 7.2.2-oth.01-2 s/w

vs.

booting from killhdinitrd 7.2.2-oth.K1 kernel into 7.2.2-oth.01-2 s/w

It depends on your definition of 'significant'.

DHCP support evolved between 3.1.5 and 7.1. If you boot from a killhdinitrd 3.1.5 kernel you will have to load an additional module to obtain an IP address using dhcp. It will be seamless with a killhdinitrd 7.2.2-oth.k1 kernel.

TCD140xxx TiVos cannot boot a killhdinitrd 3.1.5 kernel directly, the hacker must set up an in-line monte. They work fine with the killhdinitrd 7.2.2-oth.K1 kernel.

PlainBill

[sucram65]

It depends on your definition of 'significant'.


TCD140xxx TiVos cannot boot a killhdinitrd 3.1.5 kernel directly, the hacker must set up an in-line monte. They work fine with the killhdinitrd 7.2.2-oth.K1 kernel.

PlainBill

Has anyone with a TCD140060 verified that this kernel works? I don't want to have to pull my drives again. Also, I wonder if there is any advantage to it over Jamies custom 7.2.x kernel that I currently monte too from 3.1.1c.

[PlainBill]

Has anyone with a TCD140060 verified that this kernel works? I don't want to have to pull my drives again. Also, I wonder if there is any advantage to it over Jamies custom 7.2.x kernel that I currently monte too from 3.1.1c.

According to 7.1, the TCD140xxx has been verified to work properly with this kernel. As far as any advantages, it depends on what features you want. I believe Jamie compiles his kernels for better network performance; I'm not sure if he included the dhcp functionality.

If you're happy with your present configuration, remember the rule - "If it ain't broke, don't fix it."

PlainBill

[KhoaTon]

Hi all.

I'm about to killhdinitrd a TCD24004A Tivo on 7.2.2-oth.01-2-140. If I understand it correctly, killhdinitrd won't be able to modify my 7.2.2-oth.01-2-140 (yet), right?

If this is the case, then I'll need to get 7.2.2-oth.K1 and killhdinitrd it, install it onto the Tivo, in order to get access at the Tivo's Linux OS.

Once this is all done, each time a software update from Tivo comes down, it would require pulling the drive and reinstalling the killhdinitrd kernel again, since the update would overwrite the modified kernel and OS?

Thanks for any help,
Khoa

[Jamie]

I'm about to killhdinitrd a TCD24004A Tivo on 7.2.2-oth.01-2-140. If I understand it correctly, killhdinitrd won't be able to modify my 7.2.2-oth.01-2-140 (yet), right?

Right.

If this is the case, then I'll need to get 7.2.2-oth.K1 and killhdinitrd it, install it onto the Tivo, in order to get access at the Tivo's Linux OS.

Right again.

Once this is all done, each time a software update from Tivo comes down, it would require pulling the drive and reinstalling the killhdinitrd kernel again, since the update would overwrite the modified kernel and OS?

Set "upgradesoftware=false" (most people do this in the boot page) to block upgrades. You can't do this forever (see this), but you can block it until you are ready to take the upgrade. If you have network and/or serial console access, it's possible to upgrade and rehack in place without needing to pull the drive.

[KhoaTon]

Thank you very much, Jamie.

I successfully killhdinitrd my 7.2.2-oth.01-2-140 SA2 Tivo with your affirmations after making a few mistakes which required pulling the drive again (and again). I'm listing them so other beginners may avoid them:
- Disable netfilter but not replace iptables => reboot loop (Thanks djsinc99 running into this problem and reporting)
- Did not use "bootpage -p" to verify working boot partition => mods to wrong root partition
- Did not use -C option in bootpage command to set parms => very early reboot loop

Right in the middle of the modifications (took me more than a day in realtime due to other life tasks), my Tivo wanted to update to 7.2.2b-oth.01-2.140. I allowed it to do so. Upon reboot, I lost telnet to the Tivo as well as all mods. The software reload must have swapped root partition, installed new kernel and software. Had to pull the drive and redo everything.

Jamie suggested that there's a way to upgrade and rehack without pulling the drive. Any hints as to how this can be done? Does it require serial console, since telnet will be wiped with the upgrade?

Thanks,
Khoa

[Throg]

Jamie suggested that there's a way to upgrade and rehack without pulling the drive. Any hints as to how this can be done? Does it require serial console, since telnet will be wiped with the upgrade?

Scanman spelled it out for you here. All without pulling your drive.
Cheers

[diamondsw]

Scanman spelled it out for you here. All without pulling your drive.
Cheers

I assume if we're not using a monte system we need to wait for a suitably patched kernel? For now I've disabled the reboot command per Scanman's instructions, so at least the thing won't be rebooting every night.

[Jamie]

I assume if we're not using a monte system we need to wait for a suitably patched kernel?

You can use the same kernel you used before (3.1.5 or 7.2.2-oth-K1). Generally kernels don't change much within minor release cycles (7.1, 7.2, ...).

For now I've disabled the reboot command per Scanman's instructions, so at least the thing won't be rebooting every night.

Unless I'm confused, I don't think that's going to prevent 2am reboots. You need something like the "No Thanks!" patch for that, but there is no point in blocking this upgrade, as far as I can tell.

[diamondsw]

You can use the same kernel you used before (3.1.5 or 7.2.2-oth-K1). Generally kernels don't change much within minor release cycles (7.1, 7.2, ...).Unless I'm confused, I don't think that's going to prevent 2am reboots. You need something like the "No Thanks!" patch for that, but there is no point in blocking this upgrade, as far as I can tell.

Ah, I understand now. In a nutshell, I thought that the upgrade was being attempted at 2am [blocked by my bootpage], and then it reboots into it. In reality, it's just rebooting at 2am, and on boot it should notice the upgrade and load it then [blocked by my bootpage] and reboot when done. So, the 2am reboot is a completely different reboot from the one I removed.

Thanks for the kernel tip - once I'm done recording things this evening I'll upgrade (and we'll see if my "hda4=384MB but hda7=128MB" issue causes any problems).

If things do go wrong, I assume I can pull the drive and set the bootpage back to /hda4, and I'll be no worse off than I started (other than it rebooting at 2am again).