Differences between killhdinitrd'd kernels 3.1.5 and 7.2.2?

[crashHD]

What are the differences between killhdinitrd'd kernels 3.1.5 and 7.2.2.?

Anything that would make one better to use than another?

All I've been able to find by searching is the DHCP issues where 3.1.5 kernel depends on a module, and 7.2.2 is built into the kernel.

The application I have in mind is for use in Series 2 Dtivo's.
Thanks.

[PlainBill]

AFIK, the DHCP difference is the only significant one. The 3.1.5 kernel works in all DirecTiVo systems including 6.3x I believe. Personally, I'm looking for the 7.2.2 just in case a new software release for the DirecTiVo will expect the functionality built into the kernel.

PlainBill

[ScanMan]

Personally, I'm looking for the 7.2.2 just in case a new software release for the DirecTiVo will expect the functionality built into the kernel.
PB, you know drez posted a virgin 7.2.2-oth-K1 kernel here (http://www.dealdatabase.com/forum/showthread.php?p=270112#post270112)...

[Jamie]

There is one other significant difference: the 3.1.5 killhdinitrd kernel will crash on 140 model hardware. 7.2.2-oth.K1 works on that hardware. That was the raison d'etre for the 7.2.2-oth.K1 killhdinitrd support.

[PlainBill]

PB, you know drez posted a virgin 7.2.2-oth-K1 kernel here (http://www.dealdatabase.com/forum/showthread.php?p=270112#post270112)...

Nope. Thanks for pointing it out.

Edit: Correction, it seems I already downloaded it. Darn, I thought only my eyes were failing....

PlainBill

[bubba123321]

Hi , I'm rehacacking from scratch and am planning on using 7.2.2-oth.K1 killhdinitrd kernel (Linux version 2.4.20 (build@buildmaster50)) instead of the 3.1.5 Linux version 2.4.20 (build@buildmaster5) that i used the first time around. I am looking forward to getting my DHCP functionality back.

I'm wondering if i still need to copy over my files from 7.3.1 to get my wireless to work?

/lib/modules - CNXTSPDriver.o, isl38sm_usb.o, old-p80211.o, old-prism2_usb.o, p80211.o, p80211autojoin.o, pegasus.o, rtl8150.o, usb-cdc.o, usb-storage.o, usbnet.o and vnetusba.o
/platform/lib/modules - ehci-hcd.o, usb-ohci.o and usbcore.o

or will it just work now?
or should i give a crack at Jamies backport drivers?

Thanks!
-Bubba

[rbautch]

Assuming you're going to use 9.x software, then yes, you need to copy drivers that are compatible with your 7.2 kernel.

[bubba123321]

Yes, I will be running 9.3 on a SA S2. Guess I'll have to use one or the other.

I used the ones from 7.3.1 before. but will the backport drivers give me an advantage?
Thanks!
-Bubba

[Jamie]

Yes, I will be running 9.3 on a SA S2. Guess I'll have to use one or the other.

I used the ones from 7.3.1 before. but will the backport drivers give me an advantage?
Thanks!
-BubbaThe support for wireless in the backport drivers is spotty at best. If you are using a wireless dongle, you probably ought to use tivo provided drivers.

[acdc_rulz]

The support for wireless in the backport drivers is spotty at best. If you are using a wireless dongle, you probably ought to use tivo provided drivers.
Hi,
My stand-alone Tivo TCD24004A is currently running a killhdinitrd' 7.2.2 kernel. However, I am running Tivo software 9.3.0.1 and am trying to connect and use the Tivo Wireless G adapter. From what I read in other forums, there is a conflict between using the Tivo stock wireless drivers (usb-cdc.o etc.) and a 7.2.2 neutered kernel. I already tried going back to 7.3xx wireless drivers but I need WPA security and the 7.3.x drivers do not have this.

My question is, if I am able to extract a virgin copy of the 9.3xx Tivo software's kernel (which I have done already) is there an updated release of killhdinitrd that will "neuter" this kernel so I can dd it into my boot partition and thus be able to use my Tivo Wireless card?

Does the SAPper tool handle this and still give WPA functionality? Just is unfortunate if the most current kernel version that can be "neutered" by killhdinitrd (0.9.3) is 7.2.2!

Thanks.

[acdc_rulz]

Here is the serial window output when I plug/unplug the TiVO Wireless G adapter:
PLUG IN
(none):/platform/lib/modules$ hub.c: port 1, portstatus 0, change 8, 12 Mb/s
hub.c: port 1 over-current change
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 4, portstatus 100, change 0, 12 Mb/s
hub.c: port 5, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 100, change 8, 12 Mb/s
hub.c: port 1 over-current change
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 501, change 1, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 511, change 0, 480 Mb/s
hub.c: port 1, portstatus 511, change 0, 480 Mb/s
hub.c: port 1, portstatus 503, change 10, 480 Mb/s
usb.c: USB device 2 (vend/prod 0xa5c/0xbd11) is not claimed by any active driver
.
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 4, portstatus 100, change 0, 12 Mb/s
hub.c: port 5, portstatus 100, change 0, 12 Mb/s
Switching to OHCI
hub.c: port 1, portstatus 101, change 1, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 101, change 0, 12 Mb/s
hub.c: port 1, portstatus 103, change 10, 12 Mb/s
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 501, change 1, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 501, change 0, 480 Mb/s
hub.c: port 1, portstatus 511, change 0, 480 Mb/s
hub.c: port 1, portstatus 511, change 0, 480 Mb/s
hub.c: port 1, portstatus 503, change 10, 480 Mb/s
ehci handshake timeout: b4002024 0000800C 00008000 00000000
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 4, portstatus 100, change 0, 12 Mb/s
hub.c: port 5, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 100, change 2, 12 Mb/s
hub.c: port 2, portstatus 100, change 0, 12 Mb/s
hub.c: port 3, portstatus 100, change 0, 12 Mb/s
hub.c: port 1, portstatus 100, change 3, 12 Mb/s
UNPLUG
KERNEL: assertion (dev->master==NULL) failed at /build/sandbox-b-7-2-2-mr-releas
e-mips-other/b-7-2-2-mr/os/linux-2.4/net/core/dev.c(2577)

[ScanMan]

My question is, if I am able to extract a virgin copy of the 9.3xx Tivo software's kernel (which I have done already) is there an updated release of killhdinitrd that will "neuter" this kernel so I can dd it into my boot partition and thus be able to use my Tivo Wireless card?No, there is no publicly released exploit (i.e., killhdinitrd) for current kernels.Does the SAPper tool handle this and still give WPA functionality?No, the tool that shall not be named here does not give you that functionality either. Since wireless driver support is spotty, your best bet is to use the monte technique to chainload a 9.x kernel that has a null initrd. In other words, you want to boot from a killhdinitrd compatible kernel into a stock kernel that has had the initrd replaced with the replace_initrd utility.

[jt1134]

http://dealdatabase.com/forum/showpost.php?p=296723&postcount=10

[acdc_rulz]

JT/Scanman,
Thank you both very much for the help/recommendations. Using the files at the link from JT1134, I switched my S2 over to using a monte 2-step load process vs. my 3.1.5 killhdinitrd setup from before. I followed the monte steps and bogus rc.sysinit script here:

http://www.dealdatabase.com/forum/showthread.php?t=48985

and am now booting into a current 2.4.20 kernel (Tivoapp 9.3) from Tivo that has been "neutered"(initrd removed). I am now no longer getting Kernel exception errors when plugging in the TiVo wireless adapter and am using the stock wireless drivers. So far the performance is not too bad and streaming shows few if any display hiccups over wireless.

Do I have to do these steps all over again (setting up monte) when the next upgrade comes out since it will install to the alt. partition where I currently have the monte files and 9.3 initrd-removed kernel?

[ScanMan]

Do I have to do these steps all over again (setting up monte) when the next upgrade comes out since it will install to the alt. partition where I currently have the monte files and 9.3 initrd-removed kernel?Yes, you will have to perform a similar process after an upgrade. But you can save yourself some pain if you have 'upgradesoftware=false' in your bootpage and you do the manual upgrade process by modifying the 'installSw.itcl ' to not auto-reboot.

If you keep all the necessary 'monte' files as well as 'replace_initrd.mips' and 'null-linuxrc.img.gz' in one directory (/monte) off the root filesystem, you can just copy over that directory, copy over the 'bogus' rc.sysinit and rename the appropriate 'rc.*' files. Then re-run replace_initrd on the newly installed kernel and you should be good to go. Just doublecheck everything before you reboot. jt probably has a script for this he'll point you to...;)

[acdc_rulz]

Yes, you will have to perform a similar process after an upgrade. But you can save yourself some pain if you have 'upgradesoftware=false' in your bootpage and you do the manual upgrade process by modifying the 'installSw.itcl ' to not auto-reboot.

If you keep all the necessary 'monte' files as well as 'replace_initrd.mips' and 'null-linuxrc.img.gz' in one directory (/monte) off the root filesystem, you can just copy over that directory, copy over the 'bogus' rc.sysinit and rename the appropriate 'rc.*' files. Then re-run replace_initrd on the newly installed kernel and you should be good to go. Just doublecheck everything before you reboot. jt probably has a script for this he'll point you to...;)
Good to know...I had to modify one of the startup scripts as well that checks the /var (hda9) partition size. Before changing this startup script, TiVo would always wipe out my /var/hacks directory containing all the needed TiVO hack executables (ftp,telnet, etc.). Well this directory was rather large (40-50 mb.) and the default max size that TiVO would allow the /var partition to be was 40%! I changed this to be 80% but I have to do this everytime a new TiVO app. release comes as the config/startup scripts get wiped with the new installation. Another reason I changed this script was that whenever I did superpatch to the tivoapp, it always failed because I had the /hacks executables sitting on a root partition before and it took too much space for the patching to execute properly. Moving the /hacks to /var solved that problem.

I may just put the /monte directory in /var instead of /hda7 - is this better? I will need to download the replace_initrd.mips (I just copied over an already "neutered" 9.3 kernel that jt posted earlier. You have a link to that?

Thanks.

[ScanMan]

I may just put the /monte directory in /var instead of /hda7 - is this better? I will need to download the replace_initrd.mips (I just copied over an already "neutered" 9.3 kernel that jt posted earlier. You have a link to that?Putting /monte in /var will avoid you having to copy it over from root to alt-root after an upgrade. You've at least mitigated the risk of tivo wiping out your /var directory if it gets too large although I've had /var rebuilt after some filesystem corruption so you never know.;) See this (http://www.dealdatabase.com/forum/showthread.php?p=279041) thread for links to replace.initrd and the null-linuxrc.