Using 3.1.1c kernel with 3.1.1e

[cbjohnson]

I am attempteing to start my enhancement project with a Series 2 Hughes Directv tivo at 3.1.1e. I have obtained a 3.1.1c vmlinux.px file from both the PVT ISO CD and from the links on this forum. Both kernels behave the same. I have uncompressed the vmlinux.px.gz file from the PVT disk. I installed these first on a FAT 32 HD installed as hdb and run killhdinitrd against it and I get ..invalid px header. I believe the vmlinux kernel must be corrupt. I then run run killhdinitrd against the 3.1.1e kernel on the tivo disk on hda and receive an error it is unable to calculate a solution, which is what I expect on the 3.1.1e kernel so I believe I am running killhdinitrd correctly. I installed the vmlinux.px kernel on the hda6 and verified that the tivo won't boot to further verify this kernel has a problem. Does this .px file have to be converted? I have read all of the posting on this matter and believe I am missing a key element and need your help. Thank You

[TooMuchTV]

It sounds like you are on the right track but you didn't specify exactly what you did so I can't be sure. I just did this yesterday and didn't have any problems with the 3.1.1c vmlinux.px from the ftp site from the files section.

Try this:
- Download a fresh copy
- Boot any linux CD
- mount a fat32 partition
- cp vmlinux.px to that partition
- killhdinitrd vmlinux.px

Post the exact commands you are using and I'm sure we can figure this out. This is the easy part :)

[newbie]

Unless it's been changed the vmlinux.px files on the PVT ISO CD have already been modified by killhdinit and only have to be extracted from the iso file. Winace works fine.

[cbjohnson]

One of my unknowns is how to mount a FAT32 partition. I try

mount /dev/hdb /name where hdb if the FAT32 drive and I get error
can't find /dev/hdb in etc/hdb or etc/mtab

after I mount the FAT32 partition won't the file already be there since I installed it in the root of the HD?

If not will it I need to create a directory then
cp /name/vmlinux.px /mnt/directory

Thanks

[TooMuchTV]

Try this:
mkdir /mnt/dos
mount /dev/hdb1 /mnt/dos

If that doesn't work try:
mount -t vfat /dev/hdb1 /mnt/dos

You are correct in that if you put it on the FAT32 partition under Windows it should still be there when you mount it in Linux.

Let me caution you a little. If you are having problems at this point you are going to be in a world of hurt 'cause you're only on step one. I commend you for jumping right in but you might want to slow down a little bit and do some more reading before you start. I would highly recommend getting the Hinsdale guide. It will give you basic instructions on the MFSTools backup and restore, basic how-to hook up a drive, and mount them type of stuff.

I know there seems to be a LOT of information here (because there is) but there is no easy way to get where you are trying to go without reading until your eyes hurt :)

[rstaylor]

As someone else suggested I have been working my way into this slowly (about to attempt my hacking tonight in fact). When I booted off an MFS Tools boot cd I did the following. I should note that I have a non-standard disk setup. My primary drive has two primary partitions. I was only able to free up the second to reformat it as FAT32.

mount /dev/hda2 /mnt/tivo

I was then able to
cd /mnt/tivo
ls

and it worked.

The key seems to be the number of the partition if you too have multi-partitioned your disk. BTW, my first partition was NTFS which is why I could not use it.

Rich
One of my unknowns is how to mount a FAT32 partition. I try

mount /dev/hdb /name where hdb if the FAT32 drive and I get error
can't find /dev/hdb in etc/hdb or etc/mtab

after I mount the FAT32 partition won't the file already be there since I installed it in the root of the HD?

If not will it I need to create a directory then
cp /name/vmlinux.px /mnt/directory

Thanks

[cbjohnson]

Many thanks much for the great guidance. You are correct that I have much experience to gain from this experience. I will see if I can do more reading before trying the next step. I appreciate you helping me past this one. I tried your suggestions and it is moving slowly:

mkdir /mnt/dos
mount /dev/hdb1 /mnt/dos

returned
/dev/hdb1 :success
mount: you must specify the file system type

so I tried
mount -t vfat /dev/hdb1 /mnt/dos

returned
wrong fs type,bad option,bad superblock on /dev/hdb1 or too many mounted filesystem

thinking two mounts back to back was the problem on the second mount I rebooted an just dis mkdir then mount -t the same error.

I agree it is time time to read Hinesdale again, which I will. I had not problem making backup, expanding drive, restoring backup, etc.. guess this is a setback and I sure appreciate the help.

Too Much what should I try next to mount FAT 32. I have pulled out my XP HD are there machine issues that are making this worse?

[magua]

Is your FAT32 drive your primary slave? The device names are as so:

/dev/hda: primary master
/dev/hdb: primary slave
/dev/hdc: secondary master
/dev/hdd: secondary slave

Other things to ensure: That your FAT32 drive is actually FAT32. By default, Win2k and WinXP, when formatting a drive, will format it in the NTFS format. This is no good. (Linux can read from an NTFS drive, but can't reliably write to one).

If linux can't mount your FAT32 drive on /dev/hdb, then I would double check that it is, in fact, /dev/hdb, and that it is, in fact, FAT32.

[cbjohnson]

I formated the disk under XP as FAT32. It is a blank drive with only the 3.1.1c kernel installed as vmlinux.px. It is the primary secondary position.

[rstaylor]

Well, I dipped my feet into the tivo hacking world finally. I managed to upgrade the hard drive with no trouble (no big whoop right :) ) I found a 3.1.1c kernel to run killhdinitrd. This appeared to run correctly, i.e. no errors. I then used dd to copy this into /dev/hdb3 and and /dev/hdb6 to be sure that the kernel was truely replaced.

Now to my question when I run my TIVO I am still seeing 3.1.1e in the system information screen. Is that correct? Does it take this from some internal table rather than from the kernel itself?

[PlainBill]

Well, I dipped my feet into the tivo hacking world finally. I managed to upgrade the hard drive with no trouble (no big whoop right :) ) I found a 3.1.1c kernel to run killhdinitrd. This appeared to run correctly, i.e. no errors. I then used dd to copy this into /dev/hdb3 and and /dev/hdb6 to be sure that the kernel was truely replaced.

Now to my question when I run my TIVO I am still seeing 3.1.1e in the system information screen. Is that correct? Does it take this from some internal table rather than from the kernel itself?

You are correct. The Software Version information on the System Information screen is obtained from the MFS database; changes you make to the kernel or root won't change it. You are still running 3.1.1e software, there have been no code changes to the kernel between 3.1.1c and 3.1.1e.

PlainBill

[rstaylor]

You are correct. The Software Version information on the System Information screen is obtained from the MFS database; changes you make to the kernel or root won't change it. You are still running 3.1.1e software, there have been no code changes to the kernel between 3.1.1c and 3.1.1e.

PlainBill

Thanks PlainBill

I suspected that, but as I am having a networking problem (will not activate) it concerned me.

It has been a while since I did systems work at this level. Forgot how much fun it can be :)

[bnm81002]

You are correct. The Software Version information on the System Information screen is obtained from the MFS database; changes you make to the kernel or root won't change it. You are still running 3.1.1e software, there have been no code changes to the kernel between 3.1.1c and 3.1.1e.

PlainBill


I am also a newbie and have read that once a Series 2 Tivo has been hacked that when Tivo calls and downloads it wipes out those hacks? am I correct? is there anything that can be done to prevent the hacks being wiped out? I do want to have those Tivo calls for downloads though, thanks

[PlainBill]

I am also a newbie and have read that once a Series 2 Tivo has been hacked that when Tivo calls and downloads it wipes out those hacks? am I correct? is there anything that can be done to prevent the hacks being wiped out? I do want to have those Tivo calls for downloads though, thanks

Normally a TiVo will verify the software contents when it boots, removing anything added and replacing anything that has been modified. Killhdinitrd (search on it) will prevent this from happening.

As necessary, TiVo will send out software upgrades to systems. When the upgrade is installed it will wipe out any hacks that are present. Setting upgradesoftware=false (search on it) will not allow the new software to be installed.

PlainBill

[bnm81002]

Normally a TiVo will verify the software contents when it boots, removing anything added and replacing anything that has been modified. Killhdinitrd (search on it) will prevent this from happening.

As necessary, TiVo will send out software upgrades to systems. When the upgrade is installed it will wipe out any hacks that are present. Setting upgradesoftware=false (search on it) will not allow the new software to be installed.

PlainBill



I wanna receive those updates though, is there anyway that I can hack the unit and not have it eliminated while receiving the updates, anything during the hacking process that can do that?

[PlainBill]

I wanna receive those updates though, is there anyway that I can hack the unit and not have it eliminated while receiving the updates, anything during the hacking process that can do that?
:rolleyes:
Do a little more research; the answer has been discussed repeatedly. The 'upgrade block' referenced above allows the upgrade to be downloaded and saved; it is not installed. It is a trivial problem to slightly modify the install process so you can hack the new software AFTER it is installed, but BEFORE it runs - all without pulling the drive.

PlainBill

[The Only Druid]

If you're on a DirecTivo, the updates are still downloaded even though they're not installed. If you're on a standalone, you can download the slices off something like emule, then ftp them to your tivo.

Then, its as simple as modifying the installSW script to not reboot, run the script, re-copy your hacked kernel and hacks, and reboot.

[bnm81002]

If you're on a DirecTivo, the updates are still downloaded even though they're not installed. If you're on a standalone, you can download the slices off something like emule, then ftp them to your tivo.

Then, its as simple as modifying the installSW script to not reboot, run the script, re-copy your hacked kernel and hacks, and reboot.


so the only way to hack the Philips DSR704 for networking, you have to change the software back to 3.1.1c? can't hack it with the existing software 3.1.1e?

[PlainBill]

so the only way to hack the Philips DSR704 for networking, you have to change the software back to 3.1.1c? can't hack it with the existing software 3.1.1e?

Again, READ before you ask questons that have been answered repeatedly. The kernel supplied with 3.1.1c is functionally identical with the kernel supplied with 3.1.1e. The kernel is NOT the software. You're replacing a kernel for which no exploit has been developed with a functionally identical kernel that has been exploited. The SOFTWARE is still 3.1.1e.

PlainBill

[bnm81002]

Again, READ before you ask questons that have been answered repeatedly. The kernel supplied with 3.1.1c is functionally identical with the kernel supplied with 3.1.1e. The kernel is NOT the software. You're replacing a kernel for which no exploit has been developed with a functionally identical kernel that has been exploited. The SOFTWARE is still 3.1.1e.

PlainBill



all instructions have the 3.1.1c software listed? not 3.1.1e so how is it the same then when you have to change the software back to 3.1.1c when hacking Tivo?

[PlainBill]

all instructions have the 3.1.1c software listed? not 3.1.1e so how is it the same then when you have to change the software back to 3.1.1c when hacking Tivo?

Are you obtuse? The software isn't changed, the kernel is. The kernel is in the kernel partition; the software is in the root partition. The kernel supplied as part of software version 3.1.1c is functionally identical to the kernel supplied with software 3.1.1e. The SOFTWARE is different.

PlainBill

[bnm81002]

Are you obtuse? The software isn't changed, the kernel is. The kernel is in the kernel partition; the software is in the root partition. The kernel supplied as part of software version 3.1.1c is functionally identical to the kernel supplied with software 3.1.1e. The SOFTWARE is different.

PlainBill



to start saying things like what you said is very unnecessary, all you had to do was say that no matter what software version it is as long as the kernel is changed that's is all that is needed ok mr. SMARTPANTS thank you

[_SPIDEY_]

for the hughes hd, i thought the kernel used 3.1.5?? and this is what you used to replace /dev/hdd6 if you have the e revision of the software on /dev/hdd7???

[steve457]

I'm getting the error message below, through the serial port when I try to boot.

Boot failed reason=53
Ram size = 64
Service number is XXXXXXXX.
What is password?
What is password?
What is password?

This is on an HDVR2, with 3.1.1e and a killhdinitrd 3.1.1c kernel. I read somewhere that error 53 is due to the kernel being incorrect, but I tried 2 different 3.1.1c kernels and got the same error. One of the kernels came from the PTVupgrade CD.

I checked bootpage -p and it returns
boot=/dev/hda4

bootpage -b returns
Boot Partition: 3

Any ideas? I'm going to try and copy the original kernel back to partition 3 and see if it boots.

-steve

[steve457]

I just tried copying my old 3.1.1e kernel back, and I still get the same error! So I guess somehow I must be copying the kernel incorrectly or it got corrupt somehow. I used this command to copy it:

dd if=/dev/hdc3 of=/mnt/c/mykernel.px bs=1024 count=2048

I guess I'll try re-imaging the drive.. I was confident that this would be easy, since I previously had my machine running 4.0.1b using the same killhdinitrd method. I must be doing something wrong, just can't figure out what.

[Jamie]

I just tried copying my old 3.1.1e kernel back, and I still get the same error! So I guess somehow I must be copying the kernel incorrectly or it got corrupt somehow. I used this command to copy it:

dd if=/dev/hdc3 of=/mnt/c/mykernel.px bs=1024 count=2048

This command will copy the kernel off the tivo disk (if= means input file) onto a file in /mnt/c (of= means output file). Was this what you intended?

[steve457]

Yes, I used that command to copy the original from my tivo drive onto my FAT32 drive. I then did:

dd if=/mnt/c/mykernel.px of=/dev/hdc3 bs=1024

when I tried copying it back to my tivo.

Update: I just re-imaged the drive from my original 3.1.1e image (taking from my original drive). I put that drive back in the tivo, and it reboots after the Powering Up screen (doesn't make it to almost there..). Hmm... I used mfsbackup to get that image off of my original drive, so I'm not sure what's going on. I did purchase this HDVR2 off eBay, so maybe the original drive isn't actually "original". When I first got it, it had version 3.1.0 software on it, and I let the tivo upgrade itself to 3.1.1e before I pulled it.