killhdinitrd 0.9.x Support Thread

[gundan]

Scanman,

Any response to my other question(s)?

Thanks,
G

[PlainBill]

As far as files disappearing from /var, the TiVo checks partition 9 before mounting it, and will wipe it if it does not have enough free space, or sometimes just to be annoying.

PlainBill

[Deven]

I found copies of the virgin 3.1.5 and 7.2.2-oth.k1 kernels, and ran killhdinitrd on each. The HR10-250 which I just installed was upgraded to 6.3e software. I want to hack the system, so I tried to run the 6.3e software with the hacked 7.2.2-oth.k1 and 3.1.5 kernels, and neither works correctly.

When I boot the system with the hacked kernel, it runs, but very slowly -- the /var/log/kernel file indicates that it keeps turning DMA on and off, on the brand-new Seagate 750GB drive I've installed. More importantly, it cannot acquire satellite information at all. It alternates between the BOOT and ACQUIRE_MARKER states, never making any progress.

However, if I restore the kernel that came with the 6.3e update, it works fine. Does anyone know why the hacked kernels won't work correctly?

Should I consider reverting to the 3.1.5f software that was originally on the box? (I haven't tried that with the hacked 3.1.5 kernel yet...)

[Tiakon]

I tried running killhdinitrd 0.9.3 on the 7.2.2 kernel, but when I copied the hacked kernel to the drive, the message read 1+1 files in 1+1 files out. I checked the kernel with md5sum before I hacked it to see if it extracted correctly and the results were as they should have been. Any ideas?

I am using the 62small.mfs image, 500gb Seagate, DSR 704.
Any help appreciated.

[jt1134]

I tried running killhdinitrd 0.9.3 on the 7.2.2 kernel, but when I copied the hacked kernel to the drive, the message read 1+1 files in 1+1 files out. I checked the kernel with md5sum before I hacked it to see if it extracted correctly and the results were as they should have been. Any ideas?

I am using the 62small.mfs image, 500gb Seagate, DSR 704.
Any help appreciated.

huh? what exactly is the problem? all of that sounds fine.

if you want to make sure your kernel was installed correctly try : strings /dev/hdXY | grep "Linux version" where X is the location of the drive in your pc and Y is either 3 or 6 depending on where you dd'd the kernel. Check the output against the info in the first post of the killhdinitrd dev thread. If it matches up, your kernel is in the right place.

[Tiakon]

Well, according to everything that I have read, I should have seen the message

"3410+0 blocks in" and "3410+0 blocks out"

So, I was a bit perplexed when I only say 1 + 1

I haven't taken the drive out yet to see if it is going to fly because I wanted some clarification before I went to the trouble of doing so.

Thanks.

[jt1134]

don't worry about that message. depending on the exact dd command you used and the actual size of the kernel partition, those numbers can be different. check the 'strings' output and see if you get : Linux version 2.4.20 (build@buildmaster50) (gcc version 3.3.4) #1 Tue Feb 14 20:55:02 PST 2006. if you do, you're good to go.

[DocBrown]

Hi,

I've researched this for awhile and can't see what I'm missing. I have a Hughes HDVR2 that I bought straight from Weaknees that has a 250GB drive. It has now been updated from DTV to 6.4a. I've seen the thread that describes the superpatch_6.4a that should work with this.

To protect my original disk I used mfstools on the PTVUpgrade CD to create a 6.4a backup and mfsrestore to build a 'copy' of the disk. I verified that the copied disk will boot and run normally.

killhdinitrd does not seem to work on the copy and I can't seem to get the bash prompt. I know I have a working serial cable because I can see the 'What is password?" prompt if I hit CR during boot.

Here's what I do know:

The kernel version is:
Linux version 2.4.20 (build@buildmaster64) (gcc version 3.3.4) #1 Thu May 8 00:19:34 PDT 2008

used the 'strings <file>|grep 'Linux'

I've tried to run the killhdinitrd on the kernel partition and the kernel I dd'ed to my fat32 disk. I get the message "no exploit found for this kernel". Thinking maybe this is normal since my HDVR2 is not stock, I executed the bootpage command that supposedly enables the serial port and added the rc.sysinit.author file described elsewhere in the forum. No dice. No prompt. Reexamined the disk and the rc.sysinit.author disappeared. I bet this means the kernel security is still active.

just for grins, I ran killhdinitrd -R on the copied kernel to 'undo' the hack and got the same message.

What am I missing? What other steps should I be looking into? I can't find any info that describe any differences in the Weaknees disks.

Thanks
John

P.S. hmm. could it be that I need to get a different kernel? This on is VERY new (Thu May 8 00:19:34 PDT 2008) and looks like it may have come at the same time as the upgrade to 6.4a.

[ScanMan]

I've researched this for awhile...

You're definitely missing something. Read the first post here to understand what; then get the right kernel here.

[DocBrown]

You're definitely missing something. Read the first post here to understand what; then get the right kernel here.

Thanks, Maybe I should go to the newbie area

I assumed (bad idea) that because the Weaknees unit started on 6.2x (not sure now which one) that the kernel in my mfsbackup/mfsrestore was ok. And the version string except for the date, was mostly ok.

I got the prompt now by using the kernel from my other DTIVO that is already hacked to allow telnet and extraction. It's the same version you pointed me to.

But onto the next issue.....

[Spaceman_Spiff]

If I can install MFS_FTP and transfer recordings using MFS_FTP, does that mean the kernel has been successfully killhdinitrd'd? If not, how do I confirm it has been killhdinitrd'd?

[ScanMan]

If I can install MFS_FTP and transfer recordings using MFS_FTP, does that mean the kernel has been successfully killhdinitrd'd? If not, how do I confirm it has been killhdinitrd'd?

I'd say so If you can pretty much boot and retain your hacks, you're good to go. If you really want to know, watch your boot messages (or check kernel log) and compare the kernel signatures with the ones here.

[Spaceman_Spiff]

I'd say so If you can pretty much boot and retain your hacks, you're good to go. If you really want to know, watch your boot messages (or check kernel log) and compare the kernel signatures with the ones here.

I only ask cuz a friend asked me to look into his Samsung SIR4080. His recording are scrambled and he wants me to unscramble them. He has software 3.1.1e-01-2-151 with a 2.4.4-TiVo-3.0 kernel. I followed your instructions for Monte using the appropriate kmonte.o but it failed. Then I thought maybe killhdinitrd had not been applied to this kernel? Looks like I've got more reading to do!

Thanks for the quick answer ScanMan

[ScanMan]

I only ask cuz a friend asked me to look into his Samsung SIR4080. His recording are scrambled and he wants me to unscramble them. He has software 3.1.1e-01-2-151 with a 2.4.4-TiVo-3.0 kernel. I followed your instructions for Monte using the appropriate kmonte.o but it failed. Then I thought maybe killhdinitrd had not been applied to this kernel? Looks like I've got more reading to do!

Thanks for the quick answer ScanMan

So if that's the case he is using the 3.1.1c killhdinitrd kernel. Note the "2.4.4-TiVo-3.0" signature you indicated matches that kernel. So you would want to use the kmonte.o compiled for the 2.4.4 kernel not the one for 2.4.20.

[Spaceman_Spiff]

So if that's the case he is using the 3.1.1c killhdinitrd kernel. Note the "2.4.4-TiVo-3.0" signature you indicated matches that kernel. So you would want to use the kmonte.o compiled for the 2.4.4 kernel not the one for 2.4.20.

AH HA!....