killhdinitrd 0.9.x Support Thread

[JJBliss]

Please use this thread for all support questions dealing with the newly released killhdinitrd

Any posts made to the development forum that do not deal directly with furthering the development will be deleted with no prior warning.

[JJBliss]

first of all, apologies to JJBliss for hijacking his post

converting to a killhdinitrd'd config will make updates & such SO much simpler

-----

1) get killhdinitrd from the killhdinitrd thread


2) get a virgin copy of a compatible kernel from a backup / friend / whatnot, also linked to in this thread


3) put both on a fat32 hd in your pc, boot into linux or from a mfstool, ptvupgrade lba48 or sleeper (ick) iso and apply killhdinitrd to the kernel (the ptv iso currently has pre-modded kernels but that may change)


4) transfer the killhdinitrd'd kernel to /var in your sleeper'd tivo and install it to hda3 & hda6 with "dd if=/var/vmlinux.px of=/dev/hda3" and "dd if=/var/vmlinux.px of=/dev/hda6"

(at this point the tivo will still use the wacky boot parms, romfs & monte, but it'll work just fine)


5) figure out what what your root partition really is

use "bootpage -p /dev/hda" and look in the result for "root=/dev/hda4" or "root=/dev/hda7". in the brain damaged sleeper configuration, the actual root is the opposite:

hda4 means use hda7
hda7 means use hda4


6) if hda4 is your real root, update the boot parms to "root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false" with the command

bootpage -P "root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false" /dev/hda


7) set the kernel partiton to 1 less than the root partition with the command and the alternate kernel partition to 1 less than the alternate root partition with the commands

"bootpage -B 3 /dev/hda"
"bootpage -A 6 /dev/hda"


8) enjoy a nice simple FAST (no initrd scan) boot process

[JJBliss]

Place Holder #2

[JJBliss]

virgin kernels

[Juppers]

A little confusion here. It will work on a bunch of hardware, but not the latest SA S2 with the nightlight, but only if you are running one of the 2 hardcoded software versions? Is the limited software selection just cause those are the most common or cause it is still beta? Is it possible to apply it to 4.x and 5.x if the correct offsets are applied? I am guessing that the flaw is bios related, but can't read code well enough to tell.

[rc3105]

3.1.5 & 5.x run slightly different builds of a 2.4.20 kernel

while killhdinitrd doesn't specifically support the 5.x build yet (if ever) I can say that my 810, hdvr2 & sa2 are all quite happy running 5.2 on a 3.1.5 build

if build differences ever present a problem (5.3? 5.4?) it's feasable to boot the 3.1.5 kernel & monte. this is more usefull than the usual 3.1u5 approach because it supports HR10-250 hardware & provides uninterrupted lba48 support (don't need a slide rule for unusual partition layouts)

the "limited sw selection" is a combination of beta status & lack of need for additional support


fyi:

you should not attempt to boot 3.1u5 & monte into a killhdinitrd'd kernel, the exploits may conflict

the second kernel in any monte chain should have it's initrd disabled with the classic killinitrd, NOT killhdinitrd

booting with a killhdinitrd'd kernel & then monte'ng into a stock or killinitrd'd kernel should work perfectly

[redstone]

Many thanks to the HD Team for providing this.

The most extensive hack I have ever done is merely add a second disk with the Hinsdale howto on my Series 1 so I am a bit nervous about trying this blind on my HDTIVO.

I would be most appeciatiave if someone who has an HDTIVO would post the steps to install this after you have done so.


Thanks

[JJBliss]

Originally Posted by redstone

Many thanks to the HD Team for providing this.

The most extensive hack I have ever done is merely add a second disk with the Hinsdale howto on my Series 1 so I am a bit nervous about trying this blind on my HDTIVO.

I would be most appeciatiave if someone who has an HDTIVO would post the steps to install this after you have done so.


Thanks

Just a heads up. That may not happen. Most of the folks with the disposable income for such a thing have experimented on less expensive tivo models before, and have a firm grasp of what their doing.

These same individuals think you need to learn it on your own, and not "follow steps". The exploit comes with sufficient enough directions that you should be able to do it merely with the skills you posses from adding another hard drive.

There will invariably be an undercurrent flowing through this thread that sort of says that if you can't do this one on your own, maybe you shouldn't be doing it.

But that's just my opinion. Good hearted folks always rise up and hold people's hands, ya know.

We'll have to see how it all plays out.

[redstone]

Originally Posted by JJBliss

Just a heads up. That may not happen. .

I'm not worried. There are several folks that I know quite well from avsforum who are trying this out as we speak.

We both know that forum has a very different type of 'undercurrent'.

[Fletch319]

So if I'm reading this correctly. This initial release was specifically designed for the kernel that runs on the hdtivo's. But in theory could be modified to do the same thing on let's say 4.0 (for us series 2 folk running 4.0). If that's the case I assume that would mean no more monte'ing and just a straight boot. This also opens up a lot of possbilities with taking official tivo upgrades without having to screw with your partitions. Of course after an upgrade you would have to repatch the kernel. Am I majorly wrong on any of this?

[JJBliss]

Originally Posted by Fletch319

So if I'm reading this correctly. This initial release was specifically designed for the kernel that runs on the hdtivo's. But in theory could be modified to do the same thing on let's say 4.0 (for us series 2 folk running 4.0). If that's the case I assume that would mean no more monte'ing and just a straight boot. This also opens up a lot of possbilities with taking official tivo upgrades without having to screw with your partitions. Of course after an upgrade you would have to repatch the kernel. Am I majorly wrong on any of this?

The initial release will work on on the 3.1.1c (2.4.4-TiVo-3.0) and 3.1.5 (2.4.20). The 3.1.5 is HDTivo only. The 3.1.1c is any Series 2 running 3.1.1c.

Yes, it can be modified to support 4.0 kernels, and submitted to HD TeAM for review and possible inclusion as stated in their release notes. This would allow for a "straight boot", as you say.

Yes, once this is all done, tivo updates should be a relatively simple proposition.

[Fletch319]

Well for what it's worth i'm working on updating the code for use with the 4.0 kernel. Unforunately since i'm not a great coder it's going to take me a lot longer than others so i have a feeling a few will beat me to the punch. In the odd chance they don't I will submit it to the developers for review

[RxMan]

Anyone out there want to share their experiences with getting the exploit going on a HR10-250?

[w2kr]

If I follow everything discussed thus far, if I want >137 GB support on a DSR704, I'd still have to monte to a LBA-48 compatible kernel, right?

[alldeadhomiez]

Originally Posted by Fletch319

So if I'm reading this correctly. This initial release was specifically designed for the kernel that runs on the hdtivo's. But in theory could be modified to do the same thing on let's say 4.0 (for us series 2 folk running 4.0). If that's the case I assume that would mean no more monte'ing and just a straight boot. This also opens up a lot of possbilities with taking official tivo upgrades without having to screw with your partitions. Of course after an upgrade you would have to repatch the kernel. Am I majorly wrong on any of this?

You don't need to monkey with the partitions to use monte. Again, that is something associated with the BASH_ENV exploit.

You can pass environment variables on the kernel command line. Like "root=/dev/hda7 MONTE=0". Then edit /etc/inittab to point to a script that decides whether to monte or to exec rc.sysinit based on whether the $MONTE variable is defined.

It would be nice if you could use the init= kernel command line parameter to do this, but alas it is not available in TiVo release kernels.