A killhdinitrd'd 3.1u5 kernel and a Monte

[NutKase]

I've started this thread to bring together the information as I know it, regarding using the new killhdinitrd 0.9.2 to patch a 31u5 kernel (or any other killhdinitrd supported kernel.)


Note: You can use this method to monte with any kernel supported by killhdinitrd. If you don't need to monte, just killhdinitrd your supported kernel, put it in the right kernel partition (3 or 6) and install your hacks.

Also, you won't lose any recordings installing this hack unless you screw it up.


I used a 31u5 kernel because this is what I had handy and because it's the same kernel we've all been using for monte for a while.

My situation: (HISTORY)
------------------------------------
I've manually monte'd my tivo's from the very beginning. I've never Sleeper'd/tivoscript'ed anything. It took me 3 months to get the first monte done but now I can do it in about 20mins

I did use romfs and had it in hda16 because that's where my/the knowledge level at that time put it.

With that situation you had the following:
-------------------------------------
dev/hda2 (nothing)
/dev/hda3 (hackable 31u5 or 3.0 kernel)
/dev/hda4 (minimal fs)

We booted from that, there was no check... then monte'd into the following... (the partition pairs 3/4 and 6/7 can be switched)

/dev/hda5 (nothing)
/dev/hda6 (normal killinitrd'd kernel)
/dev/hda7 (normal root fs)
/dev/hda8 (swap)
/dev/hda9 (/var)
(MFS partitions 10-to-whatever, in between)
/dev/hda16 (or 14, = romfs)
--------------------------------------------
Also, with that system, you had a workable monte and could add files etc. You COULD NOT use mfstools to backup your drive. MFStools backs up the active partition pair and 2 and 5. so, in this example, 2/3/4 and /5 would get backed up and not the other pair.

After the arrival of killhdinitrd 0.9.2 came the abillity to patch several kernels (the 31u5kernel is the one I have and am interested in,) and boot from it.

Thus new monte possibilities are born.

PRESENT
---------
After reading rc3105's post on monte'ing with an rc.sysinit wrapper, I decided to give it a try. You'll find his rc.sysinit.bogus below.

My sole reason is:

1. To get some experience with killhdinitrd
2. I intend on keeping a monte to allow me to experiment with test 4.0.1b-02 kernel builds
3. Give myself the ability to use the original or GPL'd MFSTools to back up and restore a monte'd drive.

I'll document my trip down this road but I WON'T be writing a guide. Concepts will be mentioned as if you know, or can find out, what I'm talking about. If you don't know yet, print and read through this thread a couple of times. Please search before asking, but feel free to ask for clarification on things or search terms.

Anyone noticing errors in the background info please pm me so I can keep this thread as clean as possible.


NutKase

[NutKase]

That said. I read as much on killhdinitrd as I could:

Here's some links. You'll need to read up on the concept of
monte , then to answer just what killhdinitrd is:

There's the official killhdinitrd release thread, the killhdinitrd support thread and my thread on my experience using killhdinitrd in a monte configuration (you're reading it) and probably a few more.


After trying to digest that and determine what, if any of it, I needed to know for my situation. I dove in.

IMPORTANT: You must be accurate distinguishing between:

1. killinitrd - The one you've always used,

(Sleeper too...,[EDIT] - I've been notified that Sleep used replace-initrd. I stand corrected. - Thanks, w2kr.)

You can use killinitrd, which many people who manually monte'd their tivos used, to do the same thing. Here's a link, just pick your software version.

It just removes/replaces the initrd, in your monte-into (vmlinux.px kernel), which would perform the checks and will overwrite your hacks if not accomplished.

2. killhdinitrd - the newly created one from HD Team that patches certain kernels to allow them to boot and pass the check themselves. This new capability allows you to boot a modified kernel (no checks) and file system and thus a monte isn't required to hack your tivo unless you still want one, like me, OR there isn't a kernel that works on your tivo software version that is supported by killhdinitrd 0.9.2.

On to the adventure
-----------------------
The first thing I had to do was see if I had an original 31u5 kernel.

I did, so I grabbed a drive, dd'd the 31u5kernel.img to a non-active partition, ran killhdinitrd and SUCCESS!

I dd'd it back out to an image (31u5HDkernel.img) for later use.

I also dd'd out the normal killinitr'd kernel to vmlinux.px

Put 'monte', 'kmonte.o' and 'vmlinux.px' in the proper places where they're called in the script version you use. In my case, I put the files in /monte.

Rename rc.sysinit to rc.sysinit.real then place rc.sysinit.bogus in /etc/rc.d renamed to rc.sysinit.

Make sure everything's executable, and hasn't been edited with a windows/DOS editor, and reboot. The boot sequence follows:

1. /etc/rc.d/rc.sysinit (which is the renamed contents of rc.sysinit.bogus) starts up, checks for monte, performs the monte if it's there or jumps into the regular/original rc.sysinit if not.

2. Monte IS there so it boot's the vmlinux.px (normal 4.0.1b-02 killinitrd'd kernel) that I've been using.


So now here's the setup:
-------------------------------------
/dev/hda2 (nothing)
/dev/hda3 (nothing) Future home of the next tivosoftware release - Kernel
/dev/hda4 (nothing) Future home of the next tivosoftware release - File System
/dev/hda5 (nothing) Future home of my hacks for backup purposes
/dev/hda6 (killhdinitrd'd 31u5HDkernel.img) Set the bootpage to boot this straight up.
/dev/hda7 (normal root fs) Added kmonte.o, monte, and vmlinux.px
/dev/hda8 (swap)

(MFS partitions in between)

/dev/hda16 (empty)

So with partitions 2, 3, 4, 5, and 16 empty I should be able to use 2 or 5 for hacks.

3/4 will be where the next upgrade of tivo software will go.

I still have to research on how to stop the upgrade (probably use InstallSW.itcl) and allow me to capture the slices, rename the rc.sysinit to rc.sysinit.real and put the .bogus one in place... yada-yada...

Here's the rc.sysinit.bogus I'm using right now (thanks rc3105). There are about 3 versions going right now, I'm researching the differences and will keep updating what I have and documenting what works for me.

I won't publish this as a file and the content is subject to change.

[EDIT] I originally posted a slightly different .bogus given to me by rc3105 BEFORE he posted the other one. I've removed that one and duplicated the one Riley posted in the killhdinitrd thread. Having a different one posted caused confusion with the goal here. The goal here is simply to document the use of killhdinitrd and an rc.sysinit wrapper script to monte a tivo, and provide users with the knowledge to begin their own hacking using killhdinitrd.

#!/bin/bash
# bogus rc.sysinit, checks for monte
export PATH=/sbin:/bin:/tivobin:/tvbin:.:/:/etc/rc.d
export TERM=xterm
export PS1='\h:\w$ '

#enable this next line if you're paranoid
#/bin/bash</dev/ttyS2&>/dev/ttyS2&

bootparm=`/sbin/bootpage -p /dev/hda`

if [ "$sp" != "true" ]; then
  echo "sp=\"$sp\" must be first pass, trying to run monte"
  /sbin/insmod -f /monte/kmonte.o
  /monte/monte /monte/vmlinux.px "$bootparm sp=true"
else
  echo "sp=\"$sp\" must be second pass"
  exec /etc/rc.d/rc.sysinit.real
fi
echo "monte sysinit wrapper complete, you're on your own"

NutKase

[NutKase]

I've monte'd 2 drives with the method mentioned. I've also mfsbackup'd and restored the same system. Monte intact!

Also, I have two small issues:

Just for my understanding I'm trying to figure out what's stored in $sp?

I'm sure it's just the beer though .

Also, my serial output ends right after the monte starts and I get nothing, like:

bootparm: "root=/dev/hda7 upgradesoftware=false dsscon=true console=2,115200

<snip>

monte: total pages used: 402 for image, 2 for indirect tables, 1 for reload
code

I'm not sure about that but still chasing it as I did get a full output even through the monte on my first attempt.

[EDIT]Added the bold above to my bootpage via telnet and it works fine, logging all the way through.


[EDIT]Added the upgradesoftware=false to the bootpage and removed it from my original .bogus. You can do this by using this command with the drive in your computer:

/path/to/bootpage -P "root=/dev/hda# upgradesoftware=false dsscon=true console=2,115200"  -C /dev/hdx

x is where you mount your tivodrive
# is the partition of your / (root)

OR, you can also edit your bootpage after you get your drive installed by leaving off the -C and /dev/hdx location information like:

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

NutKase

[NutKase]

If you're hacking your tivo for the first time you might not know what files you need to add or which could use some editing. So while you have your tivo drive still out...

Add the basic unix commands that aren't included on your tivo.
------------------------------------------------------------------------
You could install busybox, which has hundreds of commands, most of which you won't use and was installed by Sleeper...

or

You can just install devbin which is much smaller, was also installed by Sleeper, and includes most of what you need.

One other must-have file is ps.

Here's a link to the sourceforge page so you can read about the files.

Also, AlphaWolf is maintaining an All-In-One S2 utilities collection but I think 14meg is too big and I haven't needed half of them. Devbin and a couple more have worked fine for me for years and I've never even installed busybox.

Just untar them into /bin and you won't even have to edit your path.

To Uncompress
tar -xzvf /path/to/files.tgz


Edit your /etc/rc.d/rc.sysinit:
------------------------------------------------------------------------
Find netfilter-enable and change both enable references to disable (about line #577 in mine) or you could just rename the /etc/netfilter.enable file.

While you're there you should add the bash and telnet lines as the last couple of lines.

I keep my telnet and bash lines as the last three of rc.sysinit so that in case I forget to chmod 755 .author I can still get in and fix things.

/bin/bash </dev/ttyS2&>/dev/ttyS2&
tnlited 23 /bin/bash -login &
setpri fifo 1 $$

Setpri keeps your hacks from keeping your tivo from acting like a tivo (bogging it down), just put it in /bin with the rest. - Thanks alldeadhomiez for compiling it for mips
------------------------------------------------------------------------


Here's a minimum .author

#!/bin/bash

/hack/tivoftpd

PATH=/sbin:/bin:/tvbin:/hack:.
TIVO_ROOT=
MFS_DEVICE=/dev/hda10
IGNOREEOF=1000
export PATH TIVO_ROOT MFS_DEVICE IGNOREEOF

The only hack I started was tivoftpd. I use the tivoftpd updated by dubbya that maintains file permissions. It cuts down on chmod typing .

Most importantly, notice that I don't keep anything in /var. It's not even in my path. You can place all your hacks in /hack, or whatever directory you want, in your / (root) file system partition, and tivo will never decide that it's full and blow it away.

You can add other lines to .author to start future hacks as you install them.


NutKase

[blueman2]

NutKase,

This is great! I too have been trying to digest all the latest developments and see where it takes me since I want to use 4.01b-02 on an HDVR2 with HMO patch. I assume the default 2.4.4 (correction, it is 2.4.18) kernel that comes with 4.01b is not compatible with the kill(hd)initird? That is why we must still monte with 31u5, right?

I will be following along on this thread with a 4.01b-02 image and see how it goes. Looking forward to it!

[alldeadhomiez]

I've started this thread to bring together the information as I know it, regarding using the new killhdinitrd 0.9.2 to patch a 31u5 kernel.

I'd use a 3.1.1c kernel instead, since it is a 2.4.4 kernel that supports the Uma6 boards without the "contigmem" workaround (and otherwise identical, for all intents and purposes).

[NutKase]

I assume the default 2.4.4 kernel that comes with 4.01b is not compatible with the killinitird? That is why we must still monte with 31u5, right?

No, actually the kernel that comes with 4.0.1b is 2.4.18.

No, that kernel isn't compatible with killhdinitrd.

Even if it was I'd still be monte'ing in order to run other 'test' or LBA48 kernels as I mentioned.

One thing, be VERY careful with the use of 'killinitrd', which you still need to get rid of the initrd in the 'normal' kernel that you're monte'ing into...

and 'killhdinitrd' which you use to change the parts of the hackable kernel 31u5, 3.1.1c or whatever kernel and still have it pass the checks and boot.


NutKase

[NutKase]

I'd use a 3.1.1c kernel instead, since it is a 2.4.4 kernel that supports the Uma6 boards without the "contigmem" workaround (and otherwise identical, for all intents and purposes).

Yeah, but I didn't have one and was too anxious to get going.


NutKase

[NutKase]

Hey here's a good one. I just re-montied my other tivo while it was running.

All done with FTP and Telnet. I'll run through it real quick. I use the newer version of tivoftpd so I don't have to worry about setting permissions...

IF YOU DON'T KNOW WHAT YOU'RE DOING HAVE A BACKUP, YOU'LL NEED IT.

EDIT: This post is for hacking an already monte'd tivo while it's running.

The bootpage output mentioned reflects that setup. All tivos hacked with tivoscripts.iso will give this output as will any previously manually monte'd tivo that used the 'boot the inactive-monte in the the active' method.

Remember the difference between killhdinitrd and killinitrd (read above for a refresher.)

Also, remember to chmod 755 the files you change or put on the drive and you might have to 'mount -o remount,rw /'

I run in rw all the time so I don't.

Rename rc.sysinit to rc.sysinit.real
Put rc.sysinit.bogus into /etc/rc.d and name it rc.sysinit

What .bogus does is get called up and ran by your tivo because you named it rc.sysinit. This file checks for a monte, finds it in /monte because you just put it there and runs the monte kernel called /monte/vmlinux.px. Then it runs the 'regular' rc.sysinit called rc.sysinit.real. If .bogus doesn't find a monte it'll also run your 'regular' rc.sysinit.

Make a directory called /monte and put kmonte.o and monte into it (executable, of course) and we'll put vmlinux.px there later.

Do 'bootpage -p /dev/hda' to see what your active partition is.

If it's says /dev/hda7 then that's your inactive root partition and your inactive 31u5kern is in /dev/hda6. We had to lie to the tivo to monte the 'old' way .

In this case your 'active' ie, running root partition, that you see, (and where you just stored your files) is /dev/hda4 and you are going to place your killinitrd'd kernel into it named vmlinux.px.

OK, you need to dd out your active killinitrd'd kernel so.. Make a directory called /monte.

dd if=/dev/hda3 of=/monte/vmlinux.px
This is what you will monte INTO. It's also what you've been monte'ing into.

I already had an .img of a killhdinitrd patched 31u5 kernel I named 31u5HDkern.img.

I threw that HD in just so you can keep it straight (me too).

This information is only good if you have a patched kernel image. If this is your first time through, you'll still need to pull your drive, BUT, you get the idea.

Now we put the 31u5HDkern.img onto the location of our former 'neutered by killinitrd' kernel (4.x, 3.1.1c or whateverversion) which in this example is /dev/hda3

dd if=/monte/31u5HDkern.img of=/dev/hda3

Now you should have:

/dev/hda3 31u5 kernel you just put on there from the 31u5HDkern.img
/dev/hda4 Normal root you monte into, where your hacks are stored (or /var - YUCK!)
/dev/hda6 A 31u5kern that you just nuked with killHDinitrd (Not used)
/dev/hda7 Former minimal file system used by Sleeper or manual monte (Not Used)
/dev/hda14 OR /dev/hda16 Formerly occupied by romfs (Not used)

Let's set the bootpage for our new setup:

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

Now, since the previous monte was set to boot the hackable 31u5 kernel from /dev/hda6 and the bootpage still points there, we need to 'flip' or point it to the new partition.

bootpage -f /dev/hda (Notice if you use the -C option you'll get an error)


Now go back to read only and reboot.

Why did I do this? The same reasons as my posts above:

I want all my tivos the same.
It free's up 3 partitions with which I can do stuff.
It puts the OS in standard positions that can be backed up with the normal old MFSTools 2.0 disk.

I"ll check this for typo's in a sec. BE CAREFUL! I said it before and I'll say it again...

IF YOU DON'T KNOW WHAT YOU'RE DOING HAVE A BACKUP, YOU'LL NEED IT.

If you use this info and it helps you understand what's going on let me know. I'm wondering if I'm wasting my time (so is my wife.) If you need help on how to copy, rename, mount etc.. You'll have to get it somewhere else. It's all over the board and every thread doesn't need to cover it again.

If someone calls this a guide - I'm going to take it down.
I hate all the freaking new guides. I mean how many times do we need to tell people how to copy and rename tivoftpd onto their systems.

Heck, where did that come from?


NutKase

[Lost Dog]

Hey NutKase...

Thanks for the good blog of your new monte quest. Hey, how can I copy and rename tivoftpd on my system?

Sorry, I couldn't resist.

I'm back from a wonderful weekend on the Washington coast and ready to do some hacking. I'm going to try basically what you did but on a HDVR2. I think instead of using 31u5 I'm going to use a killhdnitird 3.1.1c.

So if I'm reading this correctly...

hda3 will have a killhdinitrd 3.1.1c kernel in it.
hda4 will have the 4.0 filesystem *and* a directory called /monte which contains vmlinux.px which is the 4.0 kernel that has been nuked with killinitrd (plus monte and kmonte.o).

Hmm.... I'll give this a shot and see what happens. In the mean time, one question... This seems a bit backward to me. Wouldn't it makes more sense to have (in my case) hda3 with the 4.0 kernel (that been processed with killinitrd) then have 3.1.1c (killhdinird) as vmlinux.px? Monte would start off with 3.1.1c then switch to 4.0 in hda3.

I'm tired, maybe I'm not thinking strait.

I'll load up 4.0 on my test drive then go from there...

[NutKase]

I think instead of using 31u5 I'm going to use a killhdnitird 3.1.1c.

That should be great... any kernel that's supported should work.

So if I'm reading this correctly...

hda3 will have a killhdinitrd 3.1.1c kernel in it.
hda4 will have the 4.0 filesystem *and* a directory called /monte which contains vmlinux.px which is the 4.0 kernel that has been nuked with killinitrd (plus monte and kmonte.o).

Yes, but, keep in mind, that the actual partitions could be reversed with 6/7 depending on what your 'bootpage -p /dev/hdx' says...

Wouldn't it makes more sense to have (in my case) hda3 with the 4.0 kernel (that been processed with killinitrd) then have 3.1.1c (killhdinird) as vmlinux.px? Monte would start off with 3.1.1c then switch to 4.0 in hda3.

You've got it backwards... the killhdinitrd'd kernel starts first from /dev/hda3.

It passes the check because the only changes are in parts of the kernel that aren't 'checked'.

This killhdinitrd'd kernel, which is in /dev/hda3 then runs rc.sysinit (actually the .bogus renamed one, located in /dev/hda4) and calls vmlinux.px which is just a 'depiction' of the killinitrd'd 4.0.kernel...

This 'new' monte'd INTO kernel doesn't have any 'checks' to pass and boots up fine...

If you had the killinitrd'd 4.0 kernel in /dev/hda3 it wouldn't boot because it can't pass the check while modifies and there was NEVER a kernel that could pass the 'check' in the system.

Having the killhdinitrd'd 3.1.1c kernel in /dev/hda3 passes the 'check' then monte's to the killinitrd'd 4.0 kernel as vmlinux.px and starts your tivo.


NutKase

PS. IF THIS INFORMATION SEEMS INACCURATE - WAIT 24 HOURS - UNTIL I, (WITH MY NON-CROWN and COKE ALTERED MIND), CHECK IT. OTHERWISE I THINK IT'S GOOD.!

[Lost Dog]

You've got it backwards... the killhdinitrd'd kernel starts first from /dev/hda3.

It passes the check because the only changes are in parts of the kernel that aren't 'checked'.

This killhdinitrd'd kernel, which is in /dev/hda3 then runs rc.sysinit (actually the .bogus renamed one, located in /dev/hda4) and calls vmlinux.px which is just a 'depiction' of the killinitrd'd 4.0.kernel...

This 'new' monte'd INTO kernel doesn't have any 'checks' to pass and boots up fine...

If you had the killinitrd'd 4.0 kernel in /dev/hda3 it wouldn't boot because it can't pass the check while modifies and there was NEVER a kernel that could pass the 'check' in the system.

Having the killhdinitrd'd 3.1.1c kernel in /dev/hda3 passes the 'check' then monte's to the killinitrd'd 4.0 kernel as vmlinux.px and starts your tivo.

Yeah, I suspected my logic was screwed somewhere in there...

So /hda3 (or 6) is *required* to be booted first due to (prom?) hardware based needs. That is why you stick a complete killinitrd kernel as vmlinux.px on /hda4 so once the checks are done on /hda3 it will then pass off to (in my case) 4.0 and load the 4.0 kernel from vmlinux.px. Correct?

Ugh, this learning is making my head hurt.

I'd better go to bed then mess with this more tomorrow.

[SR712]

I tried using a 2.4.4-TiVo-3.0 killHDinitrd'd kernel with 4.0.1b-02 and it didn't work. Worked fine with 3.1.1C. I think you need 3.1.5 for 4.X.

[Lost Dog]

I tried using a 2.4.4-TiVo-3.0 killHDinitrd'd kernel with 4.0.1b-02 and it didn't work. Worked fine with 3.1.1C. I think you need 3.1.5 for 4.X.

Hmm... Not sure why it wouldn't work. I've been doing the "old skool" monte for a while using the 31u5 and several 4.0 flavors with no problems on my HDVR2. I now have a nice collection of nearly all the different 4.0x versions so I can play and test as needed.

I'm hoping to get time tonight to try:
Killhdinitrd 3.1.1c with 4.0.1b-02-2-240.

This will be using this new monte technique.

[NutKase]

I tried using a 2.4.4-TiVo-3.0 killHDinitrd'd kernel with 4.0.1b-02 and it didn't work. Worked fine with 3.1.1C. I think you need 3.1.5 for 4.X.

I don't think there's any reason that wouldn't work. Whatever kernel that you can get, that killhdinitrd will patch, should be fine.

What EXACT "2.4.4-TiVo-3.0 killHDinitrd'd kernel" did you try?

I've just described the 31u5kernel with 4.0.1b-02... Works Great!

I hope you don't think that I was mistaken...? I did it myself ...

One thing that may be different is that if you have a DTivo it 'might' be different... I don't think so but, I'm just trying to give you the benefit of the doubt.

The kernel you killhdinitrd patched, if successful, is irrelevant to the 4.0.1b-02 OS or any other OS.

I think something you did was different and I think my posts are correct, at least it worked for me.


NutKase