two card monte with the kernel? A new possibility for hacking the HDVR2 w/o prom mods

[mrblack51]

I was looking around, trying to figure out some way to hack the hdvr2 w/o modifying the prom. I recalled something from the xbox-linux team's presentation for CCC, which was something close to "once you break the chain of trust, the box is forever compromised." I thought to myself: "self, if we can load one kernel via BASH_ENV, why can't we load a second kernel?"

I set that aside for a bit, but then descided to look around again, and ran across this link: http://www.scyld.com/products/beowulf/software/monte.html

basically, we would boot into 3.1.U5, which would chain-load whatever version we wanted on the alternate partition set. im still working on it, but its definitely a start.


EDIT:

not to step on mrblack's toes, but things have changed so I've closed this thread & started a new one

two card monte with the kernel evolves in 2004 (http://www.dealdatabase.com/forum/showthread.php?t=37226)

this thread is still an invaluable source of information for anyone wishing to learn, but should NOT be considered a howto

[orangejaylove]

ok remember im a green newb but would that mean you could have 3.1 load then "chain load" 2.5 or would the chipset differences and stuff negate that...

also you couldn't do this with 3.2 because of the signed stuff, all modifcations for file would be erased or something right...

just let me know if I'm anywhere near begining to understand this stuff

[mrblack51]

Originally posted by orangejaylove
ok remember im a green newb but would that mean you could have 3.1 load then "chain load" 2.5 or would the chipset differences and stuff negate that...

also you couldn't do this with 3.2 because of the signed stuff, all modifcations for file would be erased or something right...

just let me know if I'm anywhere near begining to understand this stuff

no compiled binaries from an s1 can be used on an s2, and since there is no 2.5 for the HDVR2, thats a big no.

as for loading 3.2...thats the whole point. we want to be able to chain load a newer version which prevents our known hack by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack). if you are asking whether this chain loading could allow p3 cards to work, the answer is no.

[orangejaylove]

P3 cards who said anything about P3 cards

Ok so I thought that 3.2 was the version that nothing works on and the 3.1u5 was that hackable one...

if so please explain why you'd want to load 3.1 with all its hacks then have 3.1 chain load 3.2 and mess up all the hacks...

does doing this run the hacks before 3.2 checks for them or something

if thats true then yea that would be great load 3.1 run/start all your hacks then chain load 3.2 and get all your extra feature... what ever they are:rolleyes: and no worries... sounds good

then again I've been known to be wrong...

[orangejaylove]

we want to be able to chain load a newer version which prevents our known hack by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack).

ok I've read this three times

We want to be able to chain load a newer version which prevents our known hack-- why?

--by using an older version which we can compromise (3.1.u5 and the BASH_ENV hack). --wont that just shut down all the hacks...Why

[mrblack51]

we use a compromised version to break into a more secure version. this allows us to have the new features or bugfixes of a new version without leaving our bash hacks behind.

basically, its a method to get into versions higher than 3.1.u5 without flashing the prom. if you can't understand why thats good...well, i guess you should keep reading.

[orangejaylove]

so its like I said then you load a version get your hacks up in that then it loads the newer one and so on and so on... good deal if get it

[nitrous]

Great work MrBlack51!

Lateral thinking does it again.
But still, it is a bit of a stretch to see the full potential here.

If we use the bash compromise to chain load the updated OS, does that take the prom checks completely out of the picture? Each time the system is rebooted, hackinit reloads the bash stuff and anything else that would have been cleaned up by the prom checks that we put into the hackinit. BUT, once we chain into the other system, I assume that it is protected by virture of location from the prying eyes of the original, right?

Soooo, eventually, we can all expect to see the usual hacks in the rc.sysinit etc on the chained OS survive reboot without having to have them copied over from the primary boot OS (3.1.U5.), right? This limits the need to do too much in the hackinit beyond the bash and the noupdates parameter, right?

INteresting times MrB!
thanks again,
Nitrous

[burnt_soul]

I like the 2-card monte idea and it started me thinking: what if there were some sort of a hardware device that you could plug into the IDE cable which would intercept the first few IDE commands (reading the kernel to verify the signature) and instead return a "known good" quantity (i.e. the 3.1.U5 kernel image)? As soon as the first read was complete the device could revert to being a completely passive IDE passthrough.

This would be a great, non-intrusive "modchip" type solution - no soldering required. Just plug the device into the IDE cable.

The question is: does the kernel image get read once or twice? i.e. does the tivo:
a. load the kernel into memory, verify, then execute it from memory; or
b. verify the kernel on-disk, then load the kernel into memory for execution?

if it's (a) then this approach would not work.

[mrblack51]

Originally posted by burnt_soul
I like the 2-card monte idea and it started me thinking: what if there were some sort of a hardware device that you could plug into the IDE cable which would intercept the first few IDE commands (reading the kernel to verify the signature) and instead return a "known good" quantity (i.e. the 3.1.U5 kernel image)? As soon as the first read was complete the device could revert to being a completely passive IDE passthrough.

This would be a great, non-intrusive "modchip" type solution - no soldering required. Just plug the device into the IDE cable.

The question is: does the kernel image get read once or twice? i.e. does the tivo:
a. load the kernel into memory, verify, then execute it from memory; or
b. verify the kernel on-disk, then load the kernel into memory for execution?

if it's (a) then this approach would not work.

as far as i know, it loads, verifies, then executes

[TheHern]

Ok...got my cross compiler working, can build the kernel and any source. Ready to start the port of monte to MIPS.

I'm basing my initial implementation on MILO as far as moving the kernel into the correct place and beginning execution. I don't have my tivo available to me right now (wife is taping survivor), so I'm doing this blind as far as what the PROM does.

Does anyone have a disassembled PROM so I can compare that to MILO? I don't have a dissasembler for MIPS...so I'd hate to have to start down that path now.

Thanx!

[alldeadhomiez]

*bump*

VERY NICE work by MuscleNerd. I have tried this and it works as advertised.

posted elsewhere by MuscleNerd

Attached is a version of monte ported to the MIPS architecture. It comes in two parts: the module "kmonte.o" which should be inserted into the kernel using insmod. The user-level program called "monte" is then used to specify which "image.px" to load.

The "image.px" file is essentially a MIPS kernel and initrd combined into one image using TiVo's makeppceval script.

Note that monte completely bypasses TiVo's boot prom, so don't expect any signature checking of the image.px file. And if the initrd image within the image.px doesn't do any signature checking, well then there won't be any signature checking at all.

Don't forget to give monte the command line that the next kernel should use. Things like root=xx and console=2,1152000. Depending on what initrd you choose to package up, the command line will not be filtered for "approved" strings.

A number of people have been using this since February, so it shouldn't have too many kinks.

[alldeadhomiez]

remove the .bmp

[MuscleNerd]

Thanks....

The original download (and any future updates) are on alt.org (http://alt.org/forum/index.php?t=msg&th=74&start=0&rid=19)

[mrblack51]

Originally posted by MuscleNerd
Thanks....

The original download (and any future updates) are on alt.org (http://alt.org/forum/index.php?t=msg&th=74&start=0&rid=19)

Thanks for releasing this MuscleNerd. this is definitely a step forward in the s2 world.

just so you and everyone else knows, the original post about this linked to alt.org, but alldeadhomiez and I agreed that it might draw too many n00bs to alt.org, creating a bunch of extra work for the mods over there.

general FYI: alt.org is a serious dev site, not a how-to or whatnot site. as such, any general questions should be posted here rather than at alt.org, as per the rules of alt.org

[necrotaur]

Hey guys... been lurking for a couple of weeks now looking to see when an eventual hack for the S2 DTivo would come out past U5.

This is really sweet. I have one question though. Does anyone know if the DSR7000 will work with U5? I've only read that they come with 3.1.0.... but have not heard of anyone booting the U5 kernel. I am assuming this would work based on the fact that it is exactly like the HDVR2.

I would also assume that you would want to use a custom compiled version of the chain loaded kernel (newest kernel) since it still checks the sigs on the filesystem, correct?

[MuscleNerd]

Originally posted by necrotaur
I would also assume that you would want to use a custom compiled version of the chain loaded kernel (newest kernel) since it still checks the sigs on the filesystem, correct?
It's not the kernel proper that checks the filesystem signatures. It's the initrd image packaged alongside the kernel image.

So you don't have to recompile the kernel. You need to replace the initrd image with one that's more lenient (i.e. doesn't do checking).

[mrblack51]

rc3105: you can compile a kernel without initrd, and so far it works fine. of course, so does alldeadhomiez nullinitrd, and so does subuni's killinitrd for the s2. 4.0 might be another story, but i doubt it

[necrotaur]

Quick question, what initrd is attached to the kernel (e.g. nullinitrd)?

I am about to take the dive with this, with hopefully a nice step-by-step howto to post.

[mrblack51]

well, the easy thing to do is use a regular 3.1.u5 kernel, then monte a 3.1.u5 kernel which has been nullinitrd'd

remember, unless you modify your prom, the kernel that boots must be signed. once you have bash with that kernel, you can chain load and then go from there

[necrotaur]

OK, this leads back to my original question. Has anyone tested U5 on the DSR7000? I'll be willing to try anyway, but also, where can I get a U5 kernel since my unit shipped with the latest.

[mrblack51]

Originally posted by necrotaur
OK, this leads back to my original question. Has anyone tested U5 on the DSR7000? I'll be willing to try anyway, but also, where can I get a U5 kernel since my unit shipped with the latest.

no offense, but if you had done a search on the dsr7000, you would have found that its identical internally to the hdvr2. as such, anything for the hdvr2 applies to the dsr7000

[necrotaur]

My goal is to load 3.1.U5, monte the current version (initrd replaced of course) and stay with my current software, but give myself bash access and run tivoweb. Does this sound logical?

BTW, I found the U5 image... sorry for posting that... I did some more searching and got it.

[necrotaur]

Originally Posted by necrotaur
I am assuming this would work based on the fact that it is exactly like the HDVR2.

I know they are the same, but I still haven't seen anyone posting success on it. (I've done quite a bit of searching). Appearing to be the same and being exactly alike are different. I was just looking for some success stories.

That's cool, I can appreciate the fact that you must get asked the same questions over and over.

Anyhow, I'll have to try these hacks tonight and let you guys know how I make out.

[MuscleNerd]

For the HDVR2s, I recommend that you do this:

1) First (actual) boot kernel should be 3.1.U5 with the original initrd. Use its BASH_ENV vulnerability to run monte ASAP after starting up.

2) Other kernel (the one you'll actually run on, the "image.px" file) should be 3.1.0 with its initrd nullified.

That way, your system won't keep advertising that it's 3.1.U5 and in need of an update (assuming you have it hooked up to phone line or internet).

When the next big release for HDVR2 comes out, I would let the update occur, then repeat step #1, and change #2 to use the next big release's kernel (with nullified initrd).

[necrotaur]

I am going to try this ASAP. But as an FYI, Phillips is replacing my unit through DirecTV service for "a problem which may occur in the future" whatever that means. I wonder if this affects HDVR2 units...

[citivolus]

I was thinking about trying this out but wanted to run by the steps for a sanity check first:

0) extract my current U5 kernel image into a file:

dd if=/dev/hda3(6) of=/var/hack/mykernel

1) null out the initrd

replace_initrd /var/hack/mykernel /var/hack/null-linuxrc.img.gz

2) call monte in the beginning of /var/hackinit

insmod kmonte.o
monte /var/hack/mykernel

Is this correct? Also, what parameters should I pass to monte? I assume that I can also extract a 3.1 kernel image instead in step 0, then do the rest of the steps as above to load the latest version of the kernel and still keep BASH?

[Homer S]

OK...

I think I understand some of the process here.

Total Linux newbie here and I have a basic question.

How do you create the "image.px" file? It seems to have something to do with the makeppceval script but that is as far as I got. Can someone make a step-by-step for this?

I have read some of the step-by-step guides on backing up/restoring/upgrading as well as BASH_ENV exploitation of 3.1.u5-01-2-151. Interest here is specifically about the HDVR2 DTivo BTW.

Quick observation... can this thread be make sticky? Seems it is the software counterpart to the sticky thread about hacking versions above 3.1.u5-01-2-151 with a hacked PROM.

Awesome stuff BTW! I converted my APEX 660 to dual-boot by installing a new socket and PROM for various uses and this TIVO hacking stuff is right up there.

Homer Out

[mrblack51]

i will make the thread sticky when i see some information on a few issues.

[alldeadhomiez]

Originally posted by Homer S
How do you create the "image.px" file? It seems to have something to do with the makeppceval script but that is as far as I got. Can someone make a step-by-step for this?


make dep clean vmlinux.px modules

[Homer S]

mrblack51 and alldeadhomiez,

Thanks for the replies! Gotta go buy one now to put this stuff to use. I was waiting to get a solution that did not require a "mod" chip and it seems this is the way!

Homer Out

[citivolus]

Originally posted by citivolus
I was thinking about trying this out but wanted to run by the steps for a sanity check first:

0) extract my current U5 kernel image into a file:

dd if=/dev/hda3(6) of=/var/hack/mykernel

1) null out the initrd

replace_initrd /var/hack/mykernel /var/hack/null-linuxrc.img.gz

2) call monte in the beginning of /var/hackinit

insmod kmonte.o
monte /var/hack/mykernel

Is this correct? Also, what parameters should I pass to monte? I assume that I can also extract a 3.1 kernel image instead in step 0, then do the rest of the steps as above to load the latest version of the kernel and still keep BASH?

can someone who has successfully used monte please comment on my post?

thanks.

[hoopsbwc34]

Originally posted by citivolus
can someone who has successfully used monte please comment on my post?

thanks.

Yeah, I too would like a little more of a step by step of what is going on. I'm following the idea, but not the syntax.

[MuscleNerd]

Here's an overview of one way to gain shell access for an arbitrary TiVo release. I'll use the HDVR2 as an example.

1) Set things up so that your boot partition (say, partition 6) contains the 3.1.U5 kernel. Also, the root partition (boot_partition+1=7) should contain the corresponding 3.1.U5 ext2 image.

2) Use a variant of the BASH_ENV "mount" hack to gain control of 3.1.U5. The popular BASH_ENV method involves mounting a small ROMFS image onto /mnt and running a script on it called hacks. The hacks script ends up backgrounding a process that eventually runs /var/hack/hackinit. I recommend a slightly DIFFERENT APPROACH...

Why? Because in general, you don't want the 3.1.U5 software to come all the way up and start running. If your active release (4.0, etc) is very different from 3.1.U5, your MFS database would get very confused.

My suggestion is to use a version of the ROMFS with a much simpler hacks script. The hacks script should just insert the kmonte.o module and run monte, and not background anything. If possible, kmonte.o, monte, and the next kernel to load should ALL be contained on the ROMFS. That will make you immune to corruption/rebuilding of the /var partition. But if you really want to use the /var partition, go ahead and do so. You'll then end up putting the insmod and monte commands in /var/hack/hackinit instead of the ROMFS hacks file.

The important thing here is to not let the 3.1.U5 tivoapp start up. If you don't background anything in the hacks file, then /etc/rc.d/rc.sysinit will never get a chance to run, and tivoapp will be prevented from running. Another way to accomplish this (if you chose to use /var) is to add handcraft=true to your original bootparams.

3) What kernel image should you modify and use? Whichever one corresponds to your current active TiVo release. For the HDVR2, that's 3.1.0. For other S2s, it's possibly 4.0.

Modify the kernel image using one of the mentioned initrd nullifying utilities. That will prevent that software release from doing a filesystem check that removes your customizations.

I would go ahead and place the *modified* kernel onto the alternate boot partition (in this case, partition 3). Why use the modified kernel there? Well, if for some reason you end up booting from that partition (you shouldn't EVER do that...you should always boot from the 3.1.U5 image), and if you end up booting the official 3.1.0/4.0 kernel, then you'll blow away your modifications to the ext2 filesystem on partition 4. But if you've put the modified image on partition 3, then at least you'll be guaranteed to never boot from it (because the signature will be invalid...the BIOS will refuse to boot from that partition). Your TiVo will need you to manually intervene to get back on its feet, but at least your modifications will remain in place.

Another advantage to stuffing the modified kernel into /dev/hda3 is that you can feed that partition name directly to monte, and not have to save the kernel image separately as a file. That makes your ROMFS in step#2 significantly smaller, and you have even more reason to not depend on /var.

4) What bootparams should you feed to monte? At the very least, you'll want root=/dev/hda4 (in this case) and you'll still want console=2,115200

5) Oh yeah, and what about that shell access? Well, after you have everything in place, then you can go and modify /etc/rc.d/rc.sysinit on /dev/hda4 (in this case) to your heart's content.

[citivolus]

I wanted to try out the idea of stuffing the initrd-nulled kernel in /dev/hda3. I assume if I monte to that partition, then /dev/hda4 will be used for various directories (instead of /dev/hda7), including /etc/. I tried to mount /dev/hda4 to create /etc/rc.d/rc.sysinit.author (so I can have bash access), but Linux won't let me (telling me that there is a bad superblock). My understanding is that Tivo always keeps two copies of the kernel and filesystem (hda3&4 and hda6&7), and it would upgrade the one not used to the latest version. Am I doing something wrong or is my disk screwed up? I started by restoring a U5 image to a blank disk.

Then I decided to try using the /var partition instead. First I created my 3.1 image from my HDVR2. Mounted the disk with 3.1, ran dd if=/dev/hda6 of=/mnt/c/kernel.img bs=32k, then ran replace_initrd kernel.img null-linuxrc.img.gz (from the tiny-initrd sticky thread). It said it found the initrd image and replaced it with the one I provided. Then I put kmonte.o, monte, and the updated kernel.img in my /var/hack directory. Then I created a new hackinit with the following:

insmod /var/hack/kmonte.o
/var/hack/monte /var/hack/kernel.img root=/dev/hda7 console=2,115200

I created a /etc/rc.d/rc.sysinit.author to create a bash shell on the serial port and made it world executable.

I rebooted, and the tivo seemed to come up, then reboot itself, then came up again as normal. Checking the software version page, it was running U5! And of course, I had no BASH access.

any suggestions?

[alldeadhomiez]

Originally posted by citivolus
I wanted to try out the idea of stuffing the initrd-nulled kernel in /dev/hda3. I assume if I monte to that partition, then /dev/hda4 will be used for various directories (instead of /dev/hda7), including /etc/. I tried to mount /dev/hda4 to create /etc/rc.d/rc.sysinit.author (so I can have bash access), but Linux won't let me (telling me that there is a bad superblock). My understanding is that Tivo always keeps two copies of the kernel and filesystem (hda3&4 and hda6&7), and it would upgrade the one not used to the latest version. Am I doing something wrong or is my disk screwed up? I started by restoring a U5 image to a blank disk.

This is consistent with my experience. When I used mfsrestore 2.0 to write out my 3.1U5 image to a fresh drive, it did not put anything in hda3 or hda4. If you want something to be there you will need to put it there yourself.

If you tell your new kernel to mount /dev/hda7 as root, you will be booting a sanitized partition because the initrd needs to check *something* (and pass) in order to get to the point where you have control over the box. This can be verified by checking to see if rc.sysinit.author or whatever you added/changed was deleted.

[citivolus]

Assuming my fresh drive doesn't have anything in /dev/hda3 and /dev/hda4, could I do the following:

hook up a drive with the 3.1 kernel and run:
dd if=/dev/hda6 of=/mnt/c/tivo/kernel.img bs=32k

then write it out to the fresh drive with:
dd if=/mnt/c/tivo/kernel.img of=/dev/hda3 bs=32k

and then do the same with /dev/hda7 to /dev/hda4? I didn't know if anything special needed to be done to format the partitions or update a partition table as is done in Windows.

thanks.

[alldeadhomiez]

Originally posted by citivolus
Assuming my fresh drive doesn't have anything in /dev/hda3 and /dev/hda4, could I do the following:

hook up a drive with the 3.1 kernel and run:
dd if=/dev/hda6 of=/mnt/c/tivo/kernel.img bs=32k

then write it out to the fresh drive with:
dd if=/mnt/c/tivo/kernel.img of=/dev/hda3 bs=32k

and then do the same with /dev/hda7 to /dev/hda4? I didn't know if anything special needed to be done to format the partitions or update a partition table as is done in Windows.

thanks.

Copying the partitions verbatim should work, but as always if you have any doubts about what you're doing make sure everything important is backed up.

[citivolus]

I think I've got the filesystem changes straight. Originally, my Kernel 1 partition was half as small as Kernel 2, so I couldn't stuff the nulled-out kernel image there. I used pdisk to claim the space from the Bootstrap 1 image and now they are both the same. I used dd to copy a nulled out 3.1 kernel image into /dev/hda3, and copied the corresponding ext2 filesystem to /dev/hda4. However, I'm having no luck with monte.

I tried calling it via the hacks script, creating a script with the following:

#!/bin/bash
insmod kmonte.o
monte /dev/hda3 root=/dev/hda4 console=2,115200

then I put this hacks script, kmonte.o, and monte in a directory, genromfs'd it, and dd'd the resulting img to /dev/hda16.

I verified the BASH_ENV hack in the bootpage to mount /dev/hda16 and call hacks.

When I turned on the Tivo, I get the "Powering up" message for a minute, then the screen goes black, the "Powering up" message comes up again, then it boots into U5 as normal (instead of monte'ing into 3.1).

I also tried calling monte via the hackinit script, and also passing it the img file directly instead of using /dev/hda3.

Finally, I tried setting the handcraft=true bootpage parameter, then insmod'ing and calling monte by hand.

I always get the same result. I wonder if that since the "Powering up" screen is coming up twice, the Tivo is crashing after calling monte and simply rebooting. Any suggestions from people successfully using monte?

[MuscleNerd]

On the HDVR2s, one of the kernel partitions comes shipped twice as big as the other. You'll never see an image come down that is bigger than the smaller partition, though -- for obvious reasons.

You might want to look at your serial output from the HDVR2 during the boot process. The monte program makes sure the serial stuff is set up correctly before booting.

[citivolus]

Originally posted by MuscleNerd
You might want to look at your serial output from the HDVR2 during the boot process. The monte program makes sure the serial stuff is set up correctly before booting.

how can I view the serial output during the boot process? I assume you aren't referring to the bash shell redirecting stdin and stdout to stty2. i do have a serial cable connected, and i never see any output there other than the shell i start via hackinit.

playing about some more, i've found that if I put 3.1 in /dev/hda3 and U5 in /dev/hda6, even with the bootparam of root=/dev/hda7, it "sees" the later version kernel and upgrades /dev/hda6. was pretty painful today...

thanks again.

[MuscleNerd]

You'll probably need to add dsscon=true to see the kernel messages appear on that serial jack, along with console=2,115200

But if you do that, a successful boot log will show this general flow:

(1) 3.1.U5 kernel loads
(2) 3.1.U5 initrd does its thing ("Running as /linuxrc - autoscan!" followed by a bunch of "Scan.." lines)
(3) monte gets run ("monte: Two-kernel Monte for MIPS (Version 0.1)")
(4) 3.1.0 kernel loads, but *without* the initrd lines mentioned in #2

[citivolus]

I am now able to boot into U5 and monte to 3.1 while retaining BASH access. Here are the steps I used:

I used dd to extract a copy of the 3.1 kernel from my original disk:
dd if=/dev/hdc6 of=/var/hack/monte/kernel.img bs=32k

and pulled the corresponding ext2 partition:
dd if=/dev/hdc7 of=ext2.img bs=32k

then I put back the new hd and copied the ext2 image back to hda4:
dd if=ext2.img of=/dev/hdc4 bs=32k

so, on the new disk, here are the partitions:

hda3 U5 kernel (not used)
hda4 3.1 ext2 partition
hda6 U5 kernel
hda7 U5 ext2 partition

I compiled MrBlack's replace_initrd program and ran it on the 3.1 kernel file I created above (kernel.img) to neuter the initrd.

I then replaced my hackinit script to simply do the following:
/sbin/insmod /var/hack/monte/kmonte.o
/var/hack/monte/monte /var/hack/monte/kernel.img root=/dev/hda4 console=2,115200 dsscon=true upgradesoftware=false

I added "handcraft=true" to the drive's boot parameters.

Finally, I moved all the stuff I used to have in hackinit (e.g. loading USB drivers, kmem patch, etc) to /etc/rc.d/rc.sysinit.author on /dev/hda4.

Now, the system boots into U5, doesn't launch myworld thanks to the handcraft parameter, calls monte via the hackinit script, and starts a 3.1 kernel, which ultimately launches rc.sysinit.author.

One interesting thing I noted is that after doing all this, my /etc/fstab is showing /dev/hda7 mounted as /, although I definitely know it is /dev/hda4. I wonder if this may cause a future problem or corruption?

the dsscon=true and console=2,115200 boot parameters were critical in helping me out so I could see what was going on.

anyway, thanks again to MuscleNerd and alldeadhomiez for providing monte, nullinitrd, and the USB 2.0 drivers, as well as their help in getting me up and running. My HDVR2 (and I) can now rest and await the next kernel upgrade.

[MuscleNerd]

Originally posted by citivolus
One interesting thing I noted is that after doing all this, my /etc/fstab is showing /dev/hda7 mounted as /, although I definitely know it is /dev/hda4. I wonder if this may cause a future problem or corruption?
It shouldn't, because your root=/dev/hda4 bootparam is used, not the /etc/fstab entry for /. However, if you really want to fix it, just place a good version in /tmp/fstab and do:
mount -o remount,rw /dev/hda4 / && cp /tmp/fstab /etc ; mount -o remount,ro /dev/hda4
You want to minimize the amount of time you leave that partition mounted rw, if you can help it.

Interestingly, by merely "correcting" that file, you would open yourself up to boot failure during an official boot of the signed 3.1.0 kernel (because the corrected /etc/fstab would fail to match the official hash of that file). Good thing you're not using the official 3.1.0 kernel :)

[MuscleNerd]

Your setup reminded me of one detail. If you did not use the handcraft=true string, and if monte failed to load the image and reboot, your system would have come up in 3.1.U5 (which can be a bad thing...see my earlier post in this thread). So it really is important to use handcraft=true as one of the disk's bootparams, even if you use the "don't background /mnt/hacks" suggestion I made earlier.

How could monte end up failing? Well, if your /var partition gets blown away (which can happen in the normal course of things), then your setup would fail.

If anyone ever tries the idea of feeding monte the partition name directly, I'd be curious to see if that worked out. Though as I stated in my earlier post, you'd want that partition to contain a modified version of 3.1.0, not the real one.

[alldeadhomiez]

MuscleNerd (or anyone else): can anyone comment on the differences between the 3.1u5 and 3.1.0 kernels?

I have been building 2.4.4 kernels based on the 3.1/3.2 configuration posted at TiVo's site, and they seem to be compatible with the TiVo-supplied modules built for 3.1u5. Is there even a difference between the 3.1u5 and 3.1.0 kernel images, besides the signatures in the initrd? If so, what did they change? (I do not have the 3.1.0 software at the moment so I can't compare them.)

[citivolus]

I know this may be obvious, but one important difference is that the BASH_ENV hack does not work with 3.1.0.

[alldeadhomiez]

Originally posted by citivolus
I know this may be obvious, but one important difference is that the BASH_ENV hack does not work with 3.1.0.

Is that a kernel change or a linuxrc change?

BASH_ENV seems to work just fine with an initrd-free 3.1 (2.4.4) kernel built from source.

[MuscleNerd]

TiVo attaches a very restrictive initrd to their kernel. Well, really it's the "/linuxrc" executable on that initrd that's restrictive. You won't get BASH_ENV past it in a normal signature-verified boot.

The "kernel" per-se isn't stopping BASH_ENV, but since the kernel and initrd are signed as a bundle, it provides the necessary amount of security.

The only reason monte is able to work is that TiVo released a signed kernel+initrd with the hole still in it. They can't revoke the key used to sign it, since the public side of that key is in EEPROM which is read-only on HDVR2.

That 3.1.U5 kernel+initrd will forever be bootable on the HDVR2, and so the BASH_ENV will always be exploitable. They essentially ruined their whole security setup by not realizing the BASH_ENV backdoor before signing.

[alldeadhomiez]

Originally posted by MuscleNerd
That 3.1.U5 kernel+initrd will forever be bootable on the HDVR2, and so the BASH_ENV will always be exploitable. They essentially ruined their whole security setup by not realizing the BASH_ENV backdoor before signing.

And who says history doesn't repeat itself... guess that is what they get for basing their product on a hacker OS. ;)

So going back to my original question, is there a difference in code or in configuration between the 3.1u5 and 3.1.0 kernels, excluding the bundled initrd?

[geowar]

Looking thru citivolus steps I didn't see where he stripped (or nulled, etc.) the initrd from the kernel.img that he's going to monte to. Is that necessary? If the sig checking initrd is still there won't it still fail?

[Hamsterman]

Originally posted by alldeadhomiez
So going back to my original question, is there a difference in code or in configuration between the 3.1u5 and 3.1.0 kernels, excluding the bundled initrd?

Not much. I just wrote a program to compare the kernel byte by byte (NOT the header or initrd), and got less than 48 bytes difference, in two blocks, in the whole 1M+ kernel:


Difference found at fa564 : 20233237 20233331
Difference found at fa568 : 20536174 204d6f6e
Difference found at fa56c : 20536570 204f6374
Difference found at fa570 : 20323820 20323120
Difference found at fa574 : 32313a34 31383a33
Difference found at fa578 : 373a3434 393a3432
Difference found at 113e94 : 32372053 3331204d
Difference found at 113e98 : 61742053 6f6e204f
Difference found at 113e9c : 65702032 63742032
Difference found at 113ea0 : 38203231 31203138
Difference found at 113ea4 : 3a34373a 3a33393a
Difference found at 113ea8 : 34342050 34322050


I don't know what functions that corresponds to in the kernel, but it obviously can't be much. Just how is a kernel & initrd signed?

Hamsterman

[embeem]

-

[Hamsterman]

Originally posted by embeem
Those aren't functions, they're string values containing the date that the kernel was compiled.

That's what I get for posting just before I go to sleep. Looking at those locations with the hex editor would have shown me:

U5: 27 Sat Sep 28 21:47:44
01: 31 Mon Oct 21 18:39:42

U5: 27 Sat Sep 28 21:47:44
01: 31 Mon Oct 21 18:39:42

So indeed the 3.1U5 and 3.101 kernels are identical.

Hamsterman

[Dr. Phil]

Originally posted by Hamsterman
That's what I get for posting just before I go to sleep. Looking at those locations with the hex editor would have shown me:

U5: 27 Sat Sep 28 21:47:44
01: 31 Mon Oct 21 18:39:42

U5: 27 Sat Sep 28 21:47:44
01: 31 Mon Oct 21 18:39:42

So indeed the 3.1U5 and 3.101 kernels are identical.
So this is kind of like the scene where Dorothy wakes up and discovers that she didn't even need to find the Wizard to get back to Kansas.

How many of you hosers were still running 3.1u5 because you thought you needed the "official" 3.1.0 kernel to upgrade the userland? LOL

(Don't worry I did the same thing too.)

--D.

[bigboy]

At least now there will be a technique for the next revision (4.0 anyone? I miss my folders after moving from an S2 SA to a HDVR2).

All is not wasted....:)

[Hamsterman]

Originally posted by Dr. Phil
So this is kind of like the scene where Dorothy wakes up and discovers that she didn't even need to find the Wizard to get back to Kansas.

How many of you hosers were still running 3.1u5 because you thought you needed the "official" 3.1.0 kernel to upgrade the userland? LOL

(Don't worry I did the same thing too.)

--D.

Er, the KERNEL is the same, but the INIT_RD is different. In order to run the 2-kernel monte, you need the u5 because the INIT_RD that allows the BASH_ENV hack to work.

Hamsterman

[Dr. Phil]

Originally posted by Hamsterman
Er, the KERNEL is the same, but the INIT_RD is different. In order to run the 2-kernel monte, you need the u5 because the INIT_RD that allows the BASH_ENV hack to work.

But why exactly would you need the 2-kernel monte on an HDVR2, if the 3.1.0 kernel is identical to the (very BASH_ENV capable) 3.1u5 kernel? Certainly you could just use the 3.1u5 kernel+initrd bundle to run a compromised version of the 3.1.0 software if you so desired.

Not to imply that the monte isn't a very cool hack. I have already made extensive use of it. But most HDVR2 owners just won't need it until TiVo releases a new kernel for this box.

[Homer S]

Er... Question?

If 3.1.0 can be BASH_ENV exploited, did no one try it before hacking their PROMs or implementing it on 3.1.0???

If the DT2 has to have a valid, signed, kernel on it's initial boot, then 2-kernel monte would still be the way to go to eliminate (reduce really with alldeadhomiez's tiny ext2) the boot scan and patch the kernel for interesting things?

Homer Out

[Mighty LoPan]

Maybe this is a stupid question...but there's nothing preventing a person from using monte on an S2 SA, is there?

[mrblack51]

Originally posted by Mighty LoPan
Maybe this is a stupid question...but there's nothing preventing a person from using monte on an S2 SA, is there?

yes, you can use monte on an s2 sa

[MuscleNerd]

Originally posted by Dr. Phil
But why exactly would you need the 2-kernel monte on an HDVR2, if the 3.1.0 kernel is identical to the (very BASH_ENV capable) 3.1u5 kernel?
Because the day will come when the box decides to upgrade itself to 3.1.0 on its own. For me, this didn't happen for several months (for some reason). But in the end, if you leave your system running at 3.1.U5, you'll start seeing daily reboots at 2am until it succeeds in installing 3.1.0.

Also, using monte allows you to install your hacks in more "natural" places in the filesystem (instead of sticking them all in hackinit, for example). Using monte allows you to modify any 3.1.0 file in-place.

Along those lines, if you want to run a modified tivoapp (for reasons better discussed elsewhere), by far the easiest method is to monte over to a filesystem with the binary modified (instead of trying to copy over a modified version on every boot).

[MuscleNerd]

Originally posted by Homer S
If 3.1.0 can be BASH_ENV exploited, did no one try it before hacking their PROMs or implementing it on 3.1.0???
The signed 3.1.0 cannot be BASH_ENV exploited. The initrd attached to that kernel prevents it.

The BASH_ENV hole was not plugged by modifying the kernel. The string is filtered from the command line by TiVo's initrd in 3.1.0 and later versions.

[Dr. Phil]

Originally posted by MuscleNerd
Because the day will come when the box decides to upgrade itself to 3.1.0 on its own. For me, this didn't happen for several months (for some reason). But in the end, if you leave your system running at 3.1.U5, you'll start seeing daily reboots at 2am until it succeeds in installing 3.1.0.

Don't get me wrong - I have the utmost respect for what you've done on these units. monte has enabled some very interesting hacks on some users' boxes that would have been a lot more difficult without the ability to switch kernels. In particular, your work has been a godsend for SA users who thought they would never see tivoweb again when their boxes upgraded to 4.0.

But on the HDVR2, what's keeping us from running the BASH_ENV capable 3.1u5 kernel+initrd "bundle" with the 3.1.0 userland? Certainly tivoapp is not checking the build dates in the kernel to determine when to attempt an upgrade?

Also, using monte allows you to install your hacks in more "natural" places in the filesystem (instead of sticking them all in hackinit, for example). Using monte allows you to modify any 3.1.0 file in-place.

Along those lines, if you want to run a modified tivoapp (for reasons better discussed elsewhere), by far the easiest method is to monte over to a filesystem with the binary modified (instead of trying to copy over a modified version on every boot).

Indeed, monte does facilitate this, but the same thing became possible the moment somebody got a root shell with BASH_ENV. The pivot_root() syscall always could be used in lieu of monte to change / to an unchecked partition after linuxrc has completed.

[MuscleNerd]

Originally posted by Dr. Phil
Don't get me wrong - I have the utmost respect for what you've done on these units.
Thanks!
But on the HDVR2, what's keeping us from running the BASH_ENV capable 3.1u5 kernel+initrd "bundle" with the 3.1.0 userland?
Ah, that's what you meant. Nothing prevents that from working, and that's been a viable option since 3.1.0 came out. Embeem discreetly hinted that people could use that method at the time, and I more recently directly suggested that method (http://www.tivocommunity.com/tivo-vb/showthread.php?postid=1122329#post1122329) in that very long AVS thread.

Actually, I think there's one file that fails the signature check (/etc/build-version) but as long as it handles that replacement properly, things should boot okay.

[devnull]

I spend most of my time in another Tivo forum, so bear with me on this one.

My HDVR2 has long since moved to 3.1.0 (I'm not even sure I have U5 on my original backup) and the kids have amassed quite a few shows for archive.

Where is the Now Playing info kept? Is it in the ext2 partition (implying that I may be able to save current content)? If so, can it seems like I could dd my current 3.1.0 ext2 over into hda4, while installing a U5 kernel and ext2 over my current 3.1.0 in 6-7.

Does this make any sense? Basically what I'm trying to figure out is if I have some flimsy excuse to, uh, get a new HDVR2...for the sake of the family. Yeah. That's it.

gary

[alldeadhomiez]

Originally posted by devnull
I spend most of my time in another Tivo forum, so bear with me on this one.

My HDVR2 has long since moved to 3.1.0 (I'm not even sure I have U5 on my original backup) and the kids have amassed quite a few shows for archive.

Where is the Now Playing info kept? Is it in the ext2 partition (implying that I may be able to save current content)? If so, can it seems like I could dd my current 3.1.0 ext2 over into hda4, while installing a U5 kernel and ext2 over my current 3.1.0 in 6-7.

Does this make any sense? Basically what I'm trying to figure out is if I have some flimsy excuse to, uh, get a new HDVR2...for the sake of the family. Yeah. That's it.

gary

There doesn't seem to be any technical reason why you can't "downgrade" to the 3.1u5 kernel and keep your existing recordings. I have only recently gotten ahold of the 3.1.0 software though so I can't say I've done it myself.

You might want to check out the files in my "repartitioning" thread to see a way to set up a dummy kernel/root partition (with a 3.1u5 kernel and a minimal 3.1u5 root partition) that is used to invoke monte to chain-load a new kernel that boots an unchecked/custom copy of the root partition, in your case 3.1.0. This should allow you to make the changes you desire without reimaging or clobbering MFS.

[Mighty LoPan]

So it's possible to downgrade the OS without wiping the recordings? I had assumed that you'd basically follow these steps, which would wipe everything:

1) Restore SA 3.1 or HDVR U5 image to A drive
2A) Modify the scripts (I'm a bit unclear on how this is done) so that the Tivo boots out of the partition containing 3.1/U5 but will upgrade in the other partition.
2B) Setup monte to load whatever's in the upgradeable partition
3) Allow Tivo to upgrade to latest version
4) Break out the champagne

Is there a way for me to drop in an old OS version into the proper partitions on my drive without having to restore from a backup image? Can I just extract certain partitions into my drive?

[Homer S]

Lost the whole frigging weekend working on this thing (DTIVO2, DSR7000/17 actually).

I am sort of stuck.

I have tried a variety of things and can't seem to get anything much to work.

I backed up my current drive ("vanilla" working 3.1.0) and restored/expanded to larger hard drive (100+ hours) and that works.

I restored the 3.1.U5 image and that works (minus backgrounds) but would eventually upgrade or tick off DTV since it would try to update all the time.

I restored the current drive and am unclear as to how to use the 3.1.U5 kernel. Does it check itself, it's corresponding ext2 partition and the var?

It seems to me there are really 3 bits of software here:

kernel (/dev/hda6)
ext2 linux software (/dev/hda7)
tivo software (/dev/hda10)

What is checked by what and what can I replace to get BASH (i.e., what versions should each of the 3 partitions contain)?

Does a noose have 7 or 8 twists? Hard to tell here at the end...
Homer Out

[gmitch64]

Originally posted by mrblack51
yes, you can use monte on an s2 sa

Which SA versions should we use in place for the 3.1u5 and the 3.1.0 DTiVo ones?


G

[embeem]

-

[Homer S]

Originally posted by Homer S
It seems to me there are really 3 bits of software here:

kernel (/dev/hda6)
ext2 linux software (/dev/hda7)
tivo software (/dev/hda10)



So then this means that the kernel (really kernel+initrd) and ext2 partitions must be from the same version (without monte) and that the tivo software can be whatever version (these would be the two partitions labelled MFS Application...).

With monte, ext2 may contain the checked subset of the same version and that the tivo software can be whatever version.

For advanced use, this subset could exist on a typically unused partition (such as /dev/hda1) and hda4/hda7 could both contain current software which will then be upgraded. In this case, would the romfs.img (accessed by the BASH_ENV bootparam) contain any given kernel with a neutered initrd? If the root (ext2) files are on /dev/hda1, where would the intact 31U5 kernel+initrd live (either /dev/hda3, /dev/hda7 or both)?

I hate to be basic but I think my lack of success is due to not catching the complete picture here.

Homer Out

[embeem]

-

[Dr. Phil]

Thank you for your unique insights, Mr. B.M. We feel honored to bask in your presence here at DealDatabase and look forward to many more insightful posts from your account.

Originally posted by Homer S
So then this means that the kernel (really kernel+initrd) and ext2 partitions must be from the same version (without monte) and that the tivo software can be whatever version (these would be the two partitions labelled MFS Application...).

No. The tivo software resides on an ext2 partition, hda4 or hda7, and is checked by the initrd in any signed kernel. The idea here is to make a "decoy" ext2 partition containing a subset of files from the corresponding software release to **** off the initrd, then use the BASH_ENV hack to monte or pivot_root or chroot in order to mount your fully customized root partition.

For instance:

hda3 -> alt kernel (used by upgrade)
hda4 -> alt root (used by upgrade)
hda6 -> real kernel
hda7 -> real root
hda15 -> jerkoff kernel
hda16 -> jerkoff root

You would use bootpage to set the bootable kernel to hda15, and the bootable root to hda16. You would add to this bootpage a BASH_ENV command line that mounts a partition of your choosing and invokes a script that runs monte or chroot to continue the boot process. Under no circumstances shall you add any unapproved data to the jerkoff partitions.

[MuscleNerd]

The boot prom doesn't accept any ol' value as the boot partition. It's either 3 or 6.

[Dr. Phil]

Originally posted by MuscleNerd
The boot prom doesn't accept any ol' value as the boot partition. It's either 3 or 6.

I stand corrected. Guys, don't use hda15 as your jerkoff kernel partition if you want your box to boot. Thanks Muscle.

[embeem]

-

[Hamsterman]

Originally posted by embeem
The updatekernel will see that it's booting from /dev/hda3 and install the new kernel to /dev/hda6 and attempt to flip which kernel is bootable and which is the alternate. The good news is that the new kernel is installed in the correct place, bad news is that now the system wants to boot the wrong kernel -- A bootpage wrapper will probably be needed at this point to avoid changing the boot kernel.

So, after fixing up the bootpage we're left with the following

hda2 = (same)
hda3 = (same) exploitable kernel
hda4 = unused
hda5 = (same) fake root
hda6 = new kernel
hda7 = new root

boot params:
root=/dev/hda5 real_root=/dev/hda7 BASH_ENV=$(mount$(IFS)/dev/hda2$(IFS)/mnt;/mnt/initmonte)

system boots hda3
hda2 gets mounted
initmonte gets run
monte boots kernel from hda6, root=/dev/hda2 real_root=/dev/hda7
hda2 then mounts /dev/hda7 on /tivo and runs the chroot

(ie everything comes back up again with no user interaction, all hacks still in place on hda2)


.. thoughts?


Great idea. Until now, I didn't know I could mess with the hda2 and hda5 partitions. I was thinking on the order of having the u5 software perform the update, requring manual intervention, but this may be better.

If both hda3 and hda6 have an exploitable kernel, then it won't matter which kernel is booted from.

Ideally, the updatekernel would put the new kernel as a file on the hda2 partition. If that's not practical, it could be dd'd from its partition and an exploitable kernel put in its place before a reboot. Not changing which kernel is booted from isn't much of an option, since the next update will clobber the other kernel partition.

The new kernel would still have to be patched and named properly in order to work seamlessly.

Hamsterman

[alldeadhomiez]

Originally posted by Hamsterman
If both hda3 and hda6 have an exploitable kernel, then it won't matter which kernel is booted from.

You're gonna care which kernel gets booted if hda3 has 2.4.4 and hda6 has 2.4.18. ;)

Ideally, the updatekernel would put the new kernel as a file on the hda2 partition. If that's not practical, it could be dd'd from its partition and an exploitable kernel put in its place before a reboot. Not changing which kernel is booted from isn't much of an option, since the next update will clobber the other kernel partition.

IIRC, embeem has mentioned that a fresh updatekernel script comes with each software upgrade, and this script invokes the bootparm binary on the system. Although the process of overwriting bootpage with a wrapper may be somewhat clumsy, it could be a reasonably "future-proof" way to compromise the new kernel (and new bootpage binary) installed during an upgrade and to ensure that a kernel consistent with the new software version gets written to hda6 each time.

I will give this a shot once I get my hands on the 3.1.0 HDVR2 upgrade slices.

[embeem]

http://alt.org/forum/index.php?t=msg&th=74#msg_488

[citivolus]

Originally posted by geowar
Looking thru citivolus steps I didn't see where he stripped (or nulled, etc.) the initrd from the kernel.img that he's going to monte to. Is that necessary? If the sig checking initrd is still there won't it still fail?

you're right, I forgot to include that part! I updated my post accordingly.

[d7o]

Ok, it took some work but I successfully got the monte trick to work. It took some trial and error.

Here's what I did that worked, and here's what I did that didn't.

I originally had an installation of U5 on my 160 gig hd with all my recordings. Not wanting to loose those recordings I tried somewhat in vain to convert my U5 to 151 prior to doing the monte. This completelyl failed, although it may be possible for someone else. :)

That said, I ended up starting from a scratch image and this is an outline of what I did. I would suggest reading this thread, this (http://alt.org/forum/index.php?t=msg&th=74&start=0&rid=126&S=1bdd4c117845b9b6ec1810bba9648885) thread over at alt.org and it would hurt to brush up by reading the main post on this (http://www.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=90268) tivocommunity thread.

Ok, what you'll need:

An HDVR2 (this may apply to other S2 but obviously I haven't tried them).
An image, or HD, containing the 3.1.0 OS.
An image, or HD, containing the 3.1.U5 OS.
The monte itself. Download from the alt.org forum linked above.
killinitrd. Available from sourceforge (http://tivoutils.sf.net/).
The mfstools (http://star1.jongans.com/mfstools2.iso) iso burned to CD.

In this example, I'm assuming that your attached tivo hd is on hdc (secondary master), the cdrom is on hdb (primary slave) and the temporary storage drive (fat32, ext2/3, reiserfs partition), is on hda (primary master).

We'll assume that you have already removed the tivo's drive. If not, follow the instructions on tivocommunity.

1) We first need to get a backup of the 3.1.0 OS. If you already have an image of it, skip to instruction 6. Otherwise, insert the drive into the (off) computer as secondary master and boot up to the mfstools cd. As soon as you're at the # prompt you're ready for step 2.

2) We need to mount the partition where we're going to store the image.
mount /dev/hda1 /mnt/c

3) Now we're going to create the backup.
mfsbackup -f 4138 -6so /mnt/c/tivo-s2.bak /dev/hdc

4) Once thats done, and it'll take a little bit, unmount the storage partition.
umount /mnt/c

5) reboot and then power off the computer.

6) Now we need to extract a few partitions from the U5 image. If you already have this on a drive, attach the drive as secondary master, boot up to the CD, and skip to step 11. If you have this as an image, install as secondary master the drive where the monte install is going to go and we'll use it temporarily.

7) Boot to the CD and get to the # prompt.

8) We need to restore the U5 image onto this drive so that we can extract a few partitions from it. We're assuming here that your U5 image is already on the storage drive so lets mount it.
mount /dev/hda1 /mnt/c

9) Do the actual restore.
mfsrestore -s 127 -xzpi /mnt/c/<U5 image name> /dev/hdc

10) unmount and reboot (to the CD).
umount /mnt/c
reboot

11) At the prompt, we need to remount the storage drive and this time we're also going to mount the cdrom.
mount /dev/hda1 /mnt/c
mount /dev/hdb /cdrom

12) The U5 image I used had the the bootkernel at /dev/hda6 and the FS at /dev/hda7. Alternatively the kernel could be at /dev/hda3 and the FS at /dev/hda4. To find out, we'll run bootpage.
/cdrom/bootpage -p /dev/hdc

This will tell us where the root FS is. It should say something like root=/dev/hda7 or root=/dev/hda4. The kernel is always in the partition just prior to the root FS so if root=/dev/hda7 then the kernel is at /dev/hda6. If root=/dev/hda4, then the kernel is at /dev/hda3. My U5 image said that the root was at /dev/hda7 so my instructions will follow from there. Also, the tivo drive isn't connected as primary master so instead of use hda, we'll be using hdc.

13) Backup the U5 kernel
dd if=/dev/hdc6 of=/mnt/c/U5kern.img

14) Backup the U5 FS
dd if=/dev/hdc7 of=/mnt/c/U5fs.img

15) We now need to have the drive we're going to install the monte onto. If that drive is already attached (because we we're using it to temporarily restore the U5 image or because your U5 image is already on that drive), skip to step 20.

16) Unmount everything
umount /cdrom
umount /mnt/c

17) reboot
reboot

18) After it reboots, power off the machine and install the drive you want to install monte onto as secondary master. Boot up to the CD and get to the # prompt.

19) Mount the storage drive
mount /dev/hda1 /mnt/c

Due to post size limitations, continued in next post...

[d7o]

Continued from previous post...

20) Ok, its time to install everything on your new big HD.
mfsrestore -s 127 -xzpi /mnt/c/tivo-s2.bak /dev/hdc

21) After that has finished, we need to reboot so we can pick up the partition table changes.
umount /mnt/c
reboot

22) After you have rebooted, you'll need to scroll back up to check the partitions tables. Read step 12 of the tivocommunity posting above. You need to scroll back and find the last hdcXX in the partition scan. This will probably be hdc16. This is where you are going to store a ROMFS (that later). At any rate, you need to find that last partition and remember its value.

23) We need to mount everything
mount /dev/hda1 /mnt/c
mount /dev/hdb /cdrom

24) We need to find out the root FS on the new hd. It may not be the same as it was with the U5 image!
/cdrom/bootpage -p /dev/hdc

25) As before you should either get either root=/dev/hda7 or root=/dev/hda4. We are going to be installing U5 kernel and FS in the opposite location! If you got root=/dev/hda7, then you'll be installing U5 kernel into /dev/hdc3 and U5 FS into /dev/hdc4. If you got root=/dev/hda4, you'll then be installing U5 kernel into /dev/hdc6 and U5 FS into /dev/hdc7. For me, I got root=/dev/hda7 so I'll be installing U5 into /dev/hdc3 and /dev/hdc4.

One further note. mfsrestore creates /dev/hda3 (/dev/hdc3 boot up here where we've got the drive installed) as 2 megs in size. My original 3.1.0 drive had both /dev/hda3 and /dev/hda6 as 4 megs. I assume that's because Tivo wanted enough space in case things grew beyond 2 megs. All kernels currently released by Tivo are smaller than 2 megs. However, our U5 kernel is 4 megs only because we copied the full 4 megs of the partition from the backup. When we restore the U5 kernel to the 2 megs space (if you're restoring the kernel to /dev/hdc3) you will see an error message saying not everything was copied because of lack of space. This is OK. The first 2 megs were copied and thats what counts.

26) Restore the U5 kernel and U5 FS (in my case to /dev/hdc3 and /dev/hdc4 respectively)
dd if=/mnt/c/U5kern.img of=/dev/hdc3
dd if=/mnt/c/U5fs.img of=/dev/hdc4

27) We need to create a ROMFS image which will run the monte.
mkdir /mnt/c/img
cp /mnt/c/monte-tivo/kmonte.o /mnt/c/img
cp /mnt/c/monte-tivo/monte /mnt/c/img

28) We need to create a file that will run the monte
vi /mnt/c/img/runmonte

You may need to brush up on vi. If you don't like vi, have never used vi, don't know vi, etc, you can create the file as follows:
cat > /mnt/c/img/runmonte

and then type exactly the following:
#!/bin/bash

export -n BASH_ENV
BASH_ENV=

(
/sbin/insmod -f /mnt/kmonte.o
/mnt/monte /dev/hda6 "root=/dev/hda7 console=2,115200 dsscon=true"
) &

and then press 'ctrl-D' to finish the file. If using vi, type in the above and save the file and quit out of vi.

29) Now we need to create the romfs image.
/cdrom/genromfs -f /mnt/c/romfs.img -d /mnt/c/img/

30) We need to write the romfs image to the tivo drive. We use the partition we found in step 22. For me it was /dev/hdc16.
dd if=/mnt/c/romfs.img of=/dev/hdc16

31) Getting close...

32) We now need to update the bootpage. For the bootpage, we are going to be setting the root=/dev/hda4. This is the location where you stored the U5 fs. If you wrote your U5 fs to /dev/hdc4 then you'll set root=/dev/hda4. If you worte you U5 fs to /dev/hdc7, then you'll set root=/dev/hda7. Also, from step 22, you got your romfs partition. In the command below instead of using hdcXX we'll be using hdaXX. In my case, my romfs was written to /dev/hdc16 so in the command below I used /dev/hda16.

/cdrom/bootpage -P "root=/dev/hda4 BASH_ENV=\`mount\$IFS-n\$IFS/dev/hda16\$IFS/mnt;echo\$IFS/mnt/runmonte\`" -C /dev/hdc

Type in the above very carefully. Getting this wrong can cause problems.

33) Your bootpage is currently set to run the 3.1.0 OS. Since we installed the 3.1.U5 OS in the alternate boot location, we need to 'flip' the bootpage to boot to 3.1.U5.
/cdrom/bootpage -f -C /dev/hdc

34) One last thing to do. We need to killinitrd the 3.1.0 OS. Skipping this step will make you have to repeat the installation (yeah found out the hard way). You'll be reading and writing from the partition that contains your original kernel (not the U5 kernel we installed). If you wrote your U5 kernel to /dev/hdc3, then you'll be using /dev/hdc6 in this command. If you wrote your U5 kernel to /dev/hdc6, then you'll be using /dev/hdc3 in this command. I used /dev/hdc6.
dd if=/dev/hdc6 of=/mnt/c/CurrentKern.img
/mnt/c/killinitrd-s2-v3.x /mnt/c/CurrentKern.img
dd if=/mnt/c/CurrentKern.img of=/dev/hdc6

Yeah, continued in next post...

[d7o]

Continued from previous post...

35) Ok, we've got a monte installation but we really need to install some hacks. Mount the 3.1.0 FS. For me this was /dev/hdc7. It could be /dev/hdc4 if yours was backwards from mine.
mount /dev/hdc7 /mnt/tivo

36) What's hacking without a bash prompt
cat >> /mnt/tivo/etc/rc.d/rc.sysinit
/bin/bash </dev/ttyS2& >/dev/ttyS2&

end the above by typing 'ctrl-D'

If you are a vi person, you can do it your way instead of using cat.

37) The default stuff in /bin is sorely lacking.
cp -p /mnt/cdrom/devbin-s2/* /mnt/tivo/bin

38) Install whatever other hacks into /mnt/tivo as you would like. Since we killinitrd'd the 3.1.0 kernel, it'll never get wiped. Nice, eh? The hack are more stable, permanent and natural. Also noticed, we never modified the /var partition. No more restoreing hacks to the wiped /var partition. :)

39) unmount everything
umount /mnt/tivo
umount /mnt/c
umount /cdrom

40) reboot
reboot

41) Power off you computer, yank out that tivo drive and put it back in your tivo. You should be running the full 3.1.0 OS with hacks installed.

Observations/Enhancements
-----------------------------------------

I didn't get a chance to try alldeadhomiez (http://www.dealdatabase.com/forum/showthread.php?s=&threadid=25219&highlight=monte) repartitioning trick. It seems it would be neat. Of particular interest, he has a stripped down U5 fs that only contains the stuff that is checked by the initrd. It supposedly makes booting faster. I definitely wanna try it out.

Prior to monte, I used kmem (http://www.dealdatabase.com/forum/showthread.php?s=&threadid=21142&highlight=monte) to unscramble video. All that really does is modify the kernel in memory. However, since the 3.1.0 kernel doesn't need to be signed we can modify the kernel directly. The kmem thread has instructions.

I expected the monte approach to be much slower booting. Suprisingly, it didn't add a great deal of time to the boot process. The reason: the second kernel doesn't have an initrd so it doesn't do the integrity scan. With alldeadhomiez stripped down U5 fs, it would probably be faster booting monte than it would be booting the regular signed 3.1.0 OS.

Summary
--------------------------------------------------
Monte is the way to go for hacking series 2. No question about it. You can run the latest goods while running the latest hacks. You can even make it boot faster. And did I mention no more running U5 menus???

There are bound to be errors in the above instructions. I wrote the instructions out by memory, although I have a pretty good memory. If you see mistakes post a comment and I'll correct it. This could be a completely automated process. Boot up a CD that autoconverts a drive. Someone wanna do it?

Hacking potentially turns your tivo into a brick. Be smart, keep your original tivo hard drive in a safe, stored location and you shouldn't do any permanent harm.

I didn't create monte. I certainly don't get any kudos. MuscleNerd, alldeadhomiez and all you other gurus out there doing the real hacking deserve serious props.

d7o

[CFC]

Thank you d7o for the How-To. And thanks to all who initiated the monte possibillitties !! That's awesome, this will benefit alot of folks.
I have a cool project for the weekend :cool:
I Have a DSR7000 so I will be able to confirm that it works with it also (though there is little doubt ...)
Thanks
CFC

Edit: it's d7"o" not "0" hehe

[embeem]

-

[MuscleNerd]

FWIW, here's my version of "runmonte". It has several features that can come in handy:

The boot and root partitions for monte are determined automatically.
You can supply additional boot params for monte via the "prom" bootparam, which happens to be one of those that TiVo's initrd doesn't filter out. For example, if you wanted to set FOO=bar and BAZ=bat as environment variables in the system loaded via monte, you would set prom=FOO=bar,BAZ=bat as a real bootparam on disk. This allows you to change certain things without having to generate a new ROMFS.
If monte fails, or if handcraft=true is set as a real bootparam on disk, a bash shell is brought up instead of letting the U5 system continue to load.


#!/bin/bash

# Derive monte settings from the bootparams stored on disk
set -a
newboot=/dev/hda$(/sbin/bootpage -a /dev/hda)
case "$root" in
&nbsp;&nbsp;*4) newroot=/dev/hda7 ;;
&nbsp;&nbsp;*7) newroot=/dev/hda4 ;;
&nbsp;&nbsp; *) handcraft=true
esac

# Unless "handcraft" is set, immediately load the next kernel via monte.
#
# Extra bootparams for that kernel can be set via a comma-separated list
# stuffed into the original "prom" bootparam (e.g. prom=FOO=bar,BAZ=bat)
#
if [ ! "$handcraft" ]; then
&nbsp;&nbsp;/sbin/insmod -f /mnt/kmonte.o
&nbsp;&nbsp;/mnt/monte $newboot root=$newroot dsscon=true console=2,115200 \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;upgradesoftware=false ${prom//,/ }
fi

# If this point is reached, either monte failed or was never run.
# Just continually spawn off bash shells on the serial port for debugging.
export -n BASH_ENV
BASH_ENV=
while true; do /bin/bash -login</dev/ttyS2&>/dev/ttyS2; sleep 5; done


And just to avoid cut-and-paste confusion, here's the above text attached as a txt file (rename it and chmod +x it).

[xgdfalcon]

used combination of d7o, MuscleNerd, and embeems post. Now, I'm stuck in "Welcome. Powering Up", with "What is password" on the console.

Any advice?

Thanks,

[nitrous]

If you have the serial cable connected during boot up, that error will occur. Don't put the serial cable in until the second screen appears.
N|trous

[alldeadhomiez]

Originally posted by nitrous
If you have the serial cable connected during boot up, that error will occur. Don't put the serial cable in until the second screen appears.
N|trous

Merely connecting the serial cable will not cause that, as there is usually no way in software to tell whether or not there is a cable connected.

Hitting "enter" at 115200bps before the kernel starts booting is a more likely cause. (Or perhaps using a brain-dead terminal program.)

[xgdfalcon]

I redid the ROMfs and kernel partitions. I'm stuck in the GSOD loop. I've read several posts that says it should fix itself, but I let it run overnight with no such luck.

Do we know exactly might cause the GSOD? Shouldn't this be fixable without starting over?

[alldeadhomiez]

Originally posted by xgdfalcon
I redid the ROMfs and kernel partitions. I'm stuck in the GSOD loop. I've read several posts that says it should fix itself, but I let it run overnight with no such luck.

Do we know exactly might cause the GSOD? Shouldn't this be fixable without starting over?

Insufficient swap space is a common cause of GSOD loops - have you ruled this out?

Watching the kernel log messages during the GSOD may indicate whether or not swap space is being exhausted. On a standard linux system you will see the kernel start killing off processes when the memory runs out.

[xgdfalcon]

I restarted from scratch with 2 downloaded images, and it works. I must have had a bad 3.1.0 backup to start with.

Thanks again d7o, MuscleNerd, and embeem, and alldeadhomiez

[tivosohn]

Anyone has any idea why I am getting an expected ... returns 0x000... error when I try to run the killinitrd-s2-v3.x step?

dd if=/dev/hdc6 of=/mnt/c/CurrentKern.img
/mnt/c/killinitrd-s2-v3.x /mnt/c/CurrentKern.img

I tried the killinitrd against the U5 kernel, it seems to run fine, but gives that error when I ran it on a 3.1.0 kernel.

:confused:

[tivosohn]

I found out my problem. In the steps, he all the sudden swap his boot partitions from hdc3 and 4 to hdc6 and 7.

Anyway, I have a question about all these. Will these steps stop the machine from installing any future upgrades and if no, will the upgrade screw up this whole monte image I have?

[dark strider]

I would just like to say Thank You to all of you folks putting in the time to figure this out...I always learn a huge amount, and realize how much more I don't know...

Thanks again from Just An Average joe...

[Chiun]

This is from mrblack from the top of page 5.
yes, you can use monte on an s2 sa


Can someone elaborate on how you would get this to work on a SA Tivo Series II?

I've read this entire thead and it doesn't seem possible. You need BASH to load the second kernel, but you can't get BASH to work on anything post 3.1. Although I've never seen a difinative solution to getting bash at all on a SA Tivo Series II(and I've looked, lord knows I have).

[Mighty LoPan]

Chiun, I'm no expert (and I haven't done it myself yet), but I think the first step is to get a 3.1 or 3.0 image. Then you can use the BASH_ENV trick and run from there. Essentially, it's the same process that's been outlined here, except that you'll be using a different OS image to start with. If anyone else knows of any other differences, please let me know.

BTW, is "Chiun" taken from Remo Williams? I love that movie!

[Dr. Phil]

Originally posted by Chiun
Can someone elaborate on how you would get this to work on a SA Tivo Series II?

I've read this entire thead and it doesn't seem possible. You need BASH to load the second kernel, but you can't get BASH to work on anything post 3.1. Although I've never seen a difinative solution to getting bash at all on a SA Tivo Series II(and I've looked, lord knows I have).

Why are you creating a chicken-and-egg problem that doesn't really exist?

You boot any signed, BASH_ENV vulnerable kernel+initrd and then run monte to chain-load an unsigned kernel (with or without initrd) of your choosing. Not hard.

[Chiun]

BTW, is "Chiun" taken from Remo Williams? I love that movie!

Try reading The Destroyer book series, it's much better than the movie.

[Chiun]

Partly, I"m asking a valid question Dr. Phil. Every reference in this thread refers to the HDRV2, and not the SA S2. They're not the same.

I'm not an expert with this stuff, or even close to one yet, but I am learning as best as I can.

[tivosohn]

Something is weird. I tested out this setting and every works fine when it's on a single drive. Once I place the exact same image into my second drive (80GB) and did a mfsadd on it. It shows the correct size on the PC. After I placed it into my HDVR2, it gets to the download information from the satellite, then it goes to reboot the machine and stuck on the "Powering up.." screen. I put it back on my PC, my second drive only has 4 partitions on it and my first drive's bootpage show a weird string, it no longer shows the "root=/dev/.....".

Anyone know what happened or am I missing something for adding another drive using this monte image?

Thanks in advance.

[Dr. Phil]

Originally posted by Chiun
Partly, I"m asking a valid question Dr. Phil. Every reference in this thread refers to the HDRV2, and not the SA S2. They're not the same.

I'm not an expert with this stuff, or even close to one yet, but I am learning as best as I can.

Your question is valid but you are adding a condition ("you can't get BASH to work on anything post 3.1") that insinuates that you are making it into a catch-22.

You are correct in stating that software versions 3.1 and above include an initrd that precludes use of the BASH_ENV hack. Therefore you will need to boot a kernel that is from a version lower than 3.1 in order to get to the point where you can load monte. Pre-3.1 kernels exist for both SA and S2 units, and they may even be interchangeable to some extent.

[Mighty LoPan]

One more thing, Chiun - I don't think you can run an earlier OS version than what your S2 had when you first bought it. So if it's brand new, and only knows, say, 3.2 and later, you might not be able to do the monte trick at all.

[geowar]

>I don't think you can run an earlier OS version than what your S2 had when you first bought it.

I've ran 3.0.S7a on all AT&T and TiVo brand series two TiVo's and used the BASH_ENV to get in.

[geowar]

Something's not working right for me.

I have a S2 (non HDRV2) with a BASH_ENV hacked kernel/ root (v 3.0.4) in partitions 3 & 4. Comes up fine (no tivo world, but telnet, ftp, etc.).

The other kernel/root boots up into v4.0.

So I setup my BASH_ENV startup script to check for a file (named force) and if it’s found do the monte stuff instead:

[BEGIN]

#!/bin/bash

echo "/************\ " >> /var/log/MonteInt.log
echo "|* MonteInt *| " >> /var/log/MonteInt.log
echo "\************/ " >> /var/log/MonteInt.log
date >> /var/log/MonteInt.log
echo " " >> /var/log/MonteInt.log

echo "root == ${root}" >> /var/log/MonteInt.log

handcraft=false;

# Derive monte settings from the bootparams
set -a newboot=/dev/hda$(/sbin/bootpage -a /dev/hda)
case "$root" in
*4) newroot=/dev/hda7 ;;
*7) newroot=/dev/hda4 ;;
*) handcraft=true ;;
esac

if [ -a /var/log/force ]; then

echo "force - monte" >> /var/log/MonteInt.log
rm /var/log/force # so if it reboots it won’t monte.

# Unless "handcraft" is set, immediately load the next kernel (via monte).
echo "handcraft == ${handcraft}" >> /var/log/MonteInt.log

if [ "${handcraft}" != "false"]; then
echo "handcraft! skipping monte." >> /var/log/MonteInt.log
else
echo "No handcraft. monte!" >> /var/log/MonteInt.log

if [ -a /etc/rc.d/rc.sysinit.author ]; then
echo "rc.sysinit.author exists!" >> /var/log/MonteInt.log
else
echo "copying rc.sysinit.author" >> /var/log/MonteInt.log

mount -o remount,rw /
cp /mnt/hacks/monte/rc.sysinit.author /etc/rc.d/rc.sysinit.author
chmod +x /etc/rc.d/rc.sysinit.author
sync
mount -o remount,ro /
fi

/sbin/insmod /mnt/hacks/monte/kmonte.o

echo "3, 2, 1, MONTE!" >> /var/log/MonteInt.log
sync

# Extra bootparams for this kernel can be set via a comma-seperated list
# stuffed into the orginal "prom" bootparam (e.g. prom=FOO-bar,BAX=bat)
/mnt/hacks/monte/monte /mnt/hacks/monte/mykernel root=$newroot dsscon=true console=2,115200 upgradesoftware=false ${prom//,/ }
fi
else
echo "force - skip monte" >> /var/log/MonteInt.log
fi

# if this point is reached ether monte failed or was never run.
# do our "normal" (hacked) startup script

...

[END]

The "/mnt/hacks/monte/mykernel" file is the /dev/hda6 (v4.0) kernel s2_fix_kernel2'ed (It's patched & null-initrd'ed).

The problem is that it ALWAYS reboots "Starting up" again (twice) after the monte command. If I don't copy the <rc.sysinit.author> file the it will come up (v4.0) just fine.

It appears that the s2_fix_kernel2 is still doing the initrd stuff. :(

Anyone got a S2 (non HDRV2) to monte?!?

[Chiun]

geowar, would it be possible for you to writeup what you did to try and get the monte trick to work on your S2 (non-HDRV)?

I'd be willing to test this out on mine to see if it would works.

I've been trying to piece together, from the all the HDRV posts, on how to get it to work on mine, but I've had no luck so far.

I've got a 140060.

[geowar]

>geowar, would it be possible for you to writeup what you did...

Possible? yes. Probable? Not really. If I had it all working then I might attempt to write it all up; But I don't.

Besides, it's already all written up. You need the BASH_ENV hack to set everything up. Once that's working you change the hack script to monte instead.

Do a search for BASH_ENV and get that working first then re-read this thread to see what you have to do for monte.

If you have problem's getting BASH_ENV to work you may email me at geowar @ apple.com (no spaces).

As for monte, beyound this thread you know everything I do. ;-)

[TheRonster]

I have read (and read and read) this thread and would also like to take a shot at hacking my SA Tivo-Series2 with the monte approach.

My SA is, of course, at ver 4.0 (as is my backup). Could someone PM me the location of a BASH_ENV-able version for SA Series2s?

Many thanks!

TheRonster

[needo]

After the new image is installed will my USB Ethernet Adaptor still work?

[geowar]

>After the new image is installed will my USB Ethernet Adaptor still work?

Yes. The old tivo app doesn't have all the nice setup screens of v4 but will use the usb ethernet adapter if you set the dialing prefix to ",#401".

Note that you DON'T want the old tivo app to ever run. You're only booting the old kernel because the BASH_ENV hack works there. Once up, you want to use the monte trick to switch to the new (v4.0?) kernel.

[needo]

Originally posted by geowar
>After the new image is installed will my USB Ethernet Adaptor still work?

Yes. The old tivo app doesn't have all the nice setup screens of v4 but will use the usb ethernet adapter if you set the dialing prefix to ",#401".

Note that you DON'T want the old tivo app to ever run. You're only booting the old kernel because the BASH_ENV hack works there. Once up, you want to use the monte trick to switch to the new (v4.0?) kernel.

Thanks! I am a little confused on the concepts. Ive been doing a lot of reading.

After the Monte trick is installed

Tivo Boots does it boot to the v4.0 kernel (The one I have now.) or does it boot in to v3.1U5? How do I switch back and forth? Or do I need to?

Thanks for all your help.

Also how do you remove your harddrive from a Tivo?

[geowar]

> Tivo Boots does it boot to the v4.0 kernel (The one I have now.) or does it boot in to v3.1U5? How do I switch back and forth? Or do I need to?

If everything setup correctly then the TiVo boots into v3.1U5 (I'm using 3.0.4) and uses the BASH_ENV trick to execute a script that then executes the monte code to switch to the (null initrd'ed) v4.0 kernel. When this kernel launches it launches the tivo app and you're up and running v4.0.

[needo]

Very cool!

Is there a detailed walkthrough any where out there to do this with a Tivo Series 2 v4.x?

Also a howto on how to remove the harddrive from the Tivo?

[geowar]

>Is there a detailed walkthrough any where out there to do this with a Tivo Series 2 v4.x?

Not that I know of. There is a detailed walkthru of how to do the BASH_ENV trick. Once you have that then this thread details how to monte.

> Also a how to on how to remove the harddrive from the Tivo?

This varies slightly depending on your model tivo but for the most part is very simple to do. If you can't figure that out then you probably shouldn't be even trying the rest of what you'll have to do.

[Mighty LoPan]

Originally posted by needo
Also a howto on how to remove the harddrive from the Tivo? [/B]


You probably already know this, but hinsdale's guide has everything you'll ever need to know about adding and removing hard drives.

http://www.newreleasesvideo.com/hinsdale-how-to/index9.html

Of course, if you're just removing a drive and playing around with it (for the sake of the BASH_ENV & monte hack combo), some of that stuff won't be necessary. And another thing you probably already know - make a backup image of your drive before you mess with it. Hinsdale covers that, too.

[Hamsterman]

Originally posted by geowar

The "/mnt/hacks/monte/mykernel" file is the /dev/hda6 (v4.0) kernel s2_fix_kernel2'ed (It's patched & null-initrd'ed).

The problem is that it ALWAYS reboots "Starting up" again (twice) after the monte command. If I don't copy the <rc.sysinit.author> file the it will come up (v4.0) just fine.

It appears that the s2_fix_kernel2 is still doing the initrd stuff. :(

[/B]

Sorry it doesn't seem to be working. I think you're the first person to use s2_fix_kernel2! Since I'm the only one who has downloaded any of the revised files, I suspect you have the first version, which did have a problem if you used any options. The most recent version has a compiled program in addition to the c code. It works when I boot with my turbonet cd.

If you run it against your kernel with the -t option, it will cut the file size down to just over 1MB, which will tell you that the initrd is gone. If it is near 2MB, then the initrd is still there. Also, if you run it against the kernel and it was modified, it will say so. You have to use -ikt in that case. I don't know if it works directly on the kernel partition, but you aren't doing that.

I just finished double-checking the embedded initrd with a hex editor, and it exactly matches the one I was basing it on, so once it is appended it should be OK.

Hamsterman

[needo]

Ive done many searches, what exactly is s2_fix_kernel2?

Thank you.

[needo]

In working on my SA Series 2 Hack I believe the hard drive layouts are different between a Series 2 and a HDTV2. Could someone send me a dmesg | grep hda

Thank you very much.

[geowar]

Hamsterman> Sorry it doesn't seem to be working.

The -t option does strip it to just over a MB.

If I don't copy over the <rc.sysinit.author> file then when it reboots (monte) I never get past the "welcome. Powering Up..." screen and it sounds like the drive spins down. ?!?

Something ain't right. ;-)

[needo]

I got this working with an SA2. Details forthcoming a couple questions though.

Will my Tivo 4.0 kernel still get upgraded?

and

Will /var get deleted during an upgrade?

Thank you.

[Hamsterman]

Originally posted by geowar

if [ -a /etc/rc.d/rc.sysinit.author ]; then
echo "rc.sysinit.author exists!" >> /var/log/MonteInt.log
else
echo "copying rc.sysinit.author" >> /var/log/MonteInt.log

mount -o remount,rw /
cp /mnt/hacks/monte/rc.sysinit.author /etc/rc.d/rc.sysinit.author
chmod +x /etc/rc.d/rc.sysinit.author
sync
mount -o remount,ro /
fi


Well, I see one problem, but not THE problem. When this script is running, root is the 3.0 software. Thus this code snippet is sending rc.sysinit.author to the 3.0 partition, not the 4.0 partition.

Since rc.sysinit.author is in the 3.0 partition, when the unit boots the initrd will kill it and reboot. That would explain why it boots a second time.

An /mnt/altroot directory could be created, and then the $newroot partition could be mounted and checked, like:


mount $newroot /mnt/altroot
if [ -a /mnt/altroot/etc/rc.d/rc.sysinit.author ]; then
echo "rc.sysinit.author exists!" >> /var/log/MonteInt.log
else
echo "copying rc.sysinit.author" >> /var/log/MonteInt.log
cp /mnt/hacks/monte/rc.sysinit.author /mnt/altroot/etc/rc.d/rc.sysinit.author
chmod +755 /mnt/altroot/etc/rc.d/rc.sysinit.author
sync
fi
umount /mnt/altroot


I don't know what's causing the monte to fail and the unit rebooting the first time, however. I don't suppose the MonteInt.log gives any clues?

Hamsterman

[geowar]

Originally posted by Hamsterman
Well, I see one problem, but not THE problem. When this script is running, root is the 3.0 software. Thus this code snippet is sending rc.sysinit.author to the 3.0 partition, not the 4.0 partition.


LOL! Ok, I'll have to fix that! ;-)

[i]
Since rc.sysinit.author is in the 3.0 partition, when the unit boots the initrd will kill it and reboot. That would explain why it boots a second time.
[/B]

I've been assuming that it was the v4.0 (monte) boot that was rebooting but if I'm not copying to that root then it should be comming up "Normally" (without rc.sysinit.author). It's not.

[i]
I don't know what's causing the monte to fail and the unit rebooting the first time, however. I don't suppose the MonteInt.log gives any clues?
[/B]

Ok, if I delete my logs and reboot this is what get:

[First boot]


/************\
|* MonteInt *|
\************/
Fri Jan 2 00:00:11 UTC 1970

root == /dev/hda4
Toggle - monte
handcraft == false
No handcraft. monte!
newroot == /dev/hda7
Creating /mnt/altroot
mounting altroot
unmounting altroot

[Hang, reboot]

/************\
|* MonteInt *|
\************/
Fri Jan 2 00:00:11 UTC 1970

root == /dev/hda4
Toggle - skip monte
No monte. sourcing hackinit
start date
Fri Jan 2 00:00:11 UTC 1970
exec
wait for /var
start tnlited
start tivoftpd
start vserver
start mfs_ftp.tcl
finished date
Fri Jan 2 00:00:12 UTC 1970
start TiVoWeb
set the clock
Time set to: Fri Jul 11 16:00:57 2003
Have a nice day.
[END]

Ok, the wierd thing here is that I don't see any of the "rc.sysinit.author" messages between the mounting & unmounting altroot messages. Hummm. Looks like I'll have to go play some more.

Thanks for the catch!

[Hamsterman]

If the /mnt partition was mounted read-only, which I think it has to be for BASH_ENV, any attempt to create a new directory will fail. The directory /mnt/altroot must already exist before this script is run.

Second, looking closer, the first line of the if statement is:

if [ -a /mnt/altroot/etc/rc.d/rc.sysinit.author ]; then

I'm not sure what -a is, so a syntax error here could cause the entire if statement to be skipped. Try using -e (exist),

if [ -e /mnt/altroot/etc/rc.d/rc.sysinit.author ]; then

I presume there are only a couple of statements between unmounting altroot and the next log entry, so one of those statements is causing a hang: umount or insmod. I don't know if umounting a non-existant mount will cause a problem, and you've already insmod'ed before.

Hamsterman

[geowar]

Originally posted by Hamsterman
I'm not sure what -a is...


According to: <http://quong.com/shellin20/> the -a is another form of "exists". I'll switch to the -e and see if that makes any difference. Thx.

[SANJedi]

I got it!!! I got it!!! s2 SA, v4 Details also coming soon. Thanks to d7o and MuscleNerd for thier help!!!

On another note.... If anyone wants to test some code against 4.0, I'd be happy to help. I've got another HD that I use as the master so re-imaging is not a problem. (The wife insists on 4 9's for the Tivo...).

Thanks again to all on this board that helped!!!!

SanJedi

[gnumoose]

Originally posted by xgdfalcon
I restarted from scratch with 2 downloaded images, and it works. I must have had a bad 3.1.0 backup to start with.

Thanks again d7o, MuscleNerd, and embeem, and alldeadhomiez

I am very interrested in finding out where you downloaded the images from. I thought that since I am sufferring from 2AM reboots that the 3.1.0 kernel and software might have already been transferred down to me and installed on partitions 4 and 3 respectively but it doesn't appear to be the case. I'd love to stop the reboots and the other flexability that monte provides seems ideal. Unfortunately, without 3.1.0 I seem to be stuck. Any help would be appreciated,

Thanks,
Moose

[Bomber]

I have few quick questions that have me a little puzzled.

1) I have completed this monte hack according to the how to here and my ditvo (HDVR2) boots up with no proplem. Is there a way to check to make sure the monte worked correctly?

2) Would we stuff what we had in the hackinit in the runmonte?


I guess if I get bash with software version 3.1.0 showing on screen would be a pretty good guess that it is working.

Thanks

[mrblack51]

Originally posted by Bomber
I have few quick questions that have me a little puzzled.

1) I have completed this monte hack according to the how to here and my ditvo (HDVR2) boots up with no proplem. Is there a way to check to make sure the monte worked correctly?

2) Would we stuff what we had in the hackinit in the runmonte?


I guess if I get bash with software version 3.01 showing on screen would be a pretty good guess that it is working.

Thanks

if you have bash, and it is using version 3.1.0 then you are properly monte-d

[Bomber]

Thanks for the reply Mr.Black.

[tivosohn]

Can you try to do an "ls" command in your bash prompt and see if that works? For some reason my "ls" returns an invalid command for me.

[needo]

Originally posted by tivosohn
Can you try to do an "ls" command in your bash prompt and see if that works? For some reason my "ls" returns an invalid command for me.

Make sure you have devbin-s2 package copied on to your TiVo drive or the ls command will not work.

[geowar]

Originally posted by needo
Make sure you have devbin-s2 package copied on to your TiVo drive or the ls command will not work.

Also make sure that the devbin stuff is in a location that's in your path. (Or add it's location to your path.) And make sure it's all executable.

If you don't have the devbin stuff installed yet then you can type: "echo *" to list the contents of the current directory.

[Bomber]

Originally posted by tivosohn
Can you try to do an "ls" command in your bash prompt and see if that works? For some reason my "ls" returns an invalid command for me.

I can do an "ls" at bash prompt.

"dirs" = /var/tmp

"ls" =

Correlation.temp.0 ShowcaseHasProgramIndex.temp.0
Genre.temp.0 ShowcaseIdentToIdIndex.temp.0
Osd.mpkey Showing.temp.18
Program.temp.22 Tms.temp.20
ProgramToSeries.temp.18 TvFont.mpkey
ResourceMgr.mpkey fsmem.mpkey
S_EventSwitcherSocket73 mom.mpkey
SerialPortArbitrator myworld.lck
ShowcaseHasClipIndex.temp.0 tcphonehome.lck
bash-2.02#

Another quick question. My last partition was hdc14. Can you mount this partition from Bash Prompt?

I don't think tivo drive recognizes that part since it was not there from the factory.

[devnull]

I figured out that I had forgotten to put the monte files into my romfs image :-(.

The problem now seems to be that I cannot overwrite my previous romfs image! I can remount it (is shows read-only, which makes sense for a rom filesystem) but all I see is my old directory with just 'runmonte' in it.

One other strange thing worth noting is that if I try to use 'vi' to edit the runmonte file in the romfs, I get a file with zero bytes. However, if I use 'cat', everything comes out okay.

Any hints?

gary

[needo]

Originally posted by devnull
I figured out that I had forgotten to put the monte files into my romfs image :-(.

The problem now seems to be that I cannot overwrite my previous romfs image! I can remount it (is shows read-only, which makes sense for a rom filesystem) but all I see is my old directory with just 'runmonte' in it.

One other strange thing worth noting is that if I try to use 'vi' to edit the runmonte file in the romfs, I get a file with zero bytes. However, if I use 'cat', everything comes out okay.

Any hints?

gary

Recreate the romfs correctly with genromfs and then dd it as the instructions dictate.

[gnumoose]

Originally posted by gnumoose
I am very interrested in finding out where you downloaded the images from. I thought that since I am sufferring from 2AM reboots that the 3.1.0 kernel and software might have already been transferred down to me and installed on partitions 4 and 3 respectively but it doesn't appear to be the case. I'd love to stop the reboots and the other flexability that monte provides seems ideal. Unfortunately, without 3.1.0 I seem to be stuck. Any help would be appreciated,

Thanks,
Moose

I'm still looking for a 3.1.0 image. Can anybody supply me with a ftp server's address where I could download the image or do I just need to wait for it to come down over the dish? The 2AM reboots are getting annoying.
Thanks,
Moose

[David Bought]

Originally posted by gnumoose
I'm still looking for a 3.1.0 image. Can anybody supply me with a ftp server's address where I could download the image or do I just need to wait for it to come down over the dish? The 2AM reboots are getting annoying.
Thanks,
Moose

Hey, want to know what's even more annoying than the 2AM reboots? Image begging in an important sticky thread.

This is not AVS, people. If you want to beg for images, keep it in one thread that the rest of us can ignore. Do not threadcrap in the stickies.

Thank you for your cooperation.

[devnull]

Originally posted by needo
Recreate the romfs correctly with genromfs and then dd it as the instructions dictate.

Shame on me for not being more explicit. I have actually done what you said. In fact, I've done it multiple times with no effect.

I had to do this when going from the vanilla, non-monte BASH_ENV hack to the current monte hack so I know this works.

(side note: I dd'd right over the top of a mounted romfs last time and it continued like nothing changed. I was kinda suprised)

gary

[Homer S]

For whatever reason, I had a similar problem (not being able to rewrite the end partition with the romfs image). I found that creating a partition using pdisk, dd-ing /dev/zero to the partition and finally removing the partition using pdisk did the trick. I was then able to dd the genromfs image there.

I am sure that if I knew more about Linux, there is a cleaner way to reset the contents of a partition.

Good Luck,
Homer Out

[devnull]

Originally posted by Homer S
For whatever reason, I had a similar problem (not being able to rewrite the end partition with the romfs image). I found that creating a partition using pdisk, dd-ing /dev/zero to the partition and finally removing the partition using pdisk did the trick. I was then able to dd the genromfs image there.

I am sure that if I knew more about Linux, there is a cleaner way to reset the contents of a partition.

Good Luck,
Homer Out

Thanks for the tips. I'd like to clarify a few things:

My "end partition" is /dev/hda14. I think this is what you're
saying:

add /dev/hda15 with pdisk (where in /dev/hda14 do I start this?)
dd if=/dev/zero of=/dev/hda15
remove /dev/hda15
Then I can dd over /dev/hda14 again

Sound right?

gary

[gnumoose]

Originally posted by David Bought
Hey, want to know what's even more annoying than the 2AM reboots? Image begging in an important sticky thread.

This is not AVS, people. If you want to beg for images, keep it in one thread that the rest of us can ignore. Do not threadcrap in the stickies.

Thank you for your cooperation.

You know, that is pretty annoying. It's almost as annoying as unwarranted sarcasm.

[shawn]

David Bought slammin again. you go brother!
Give em hell, makes this board even more worth reading. Yer the Howard Stern of Deal Database. King of all Tivo questions put down guy.

Fer laffs i was gonna pm you asking for a hu hack script and how to get my DVR service free. So i could be slammed as well. Wouldnt be the same tho if not for all to enjoy.

[Homer S]

Originally posted by devnull
Thanks for the tips. I'd like to clarify a few things:

My "end partition" is /dev/hda14. I think this is what you're
saying:

add /dev/hda15 with pdisk (where in /dev/hda14 do I start this?)
dd if=/dev/zero of=/dev/hda15
remove /dev/hda15
Then I can dd over /dev/hda14 again

Sound right?

gary

IIRC - You want to replace hda14, not hda15, with an actual partition (same physical space). This assumes you dd the romfs to hda14. Then proceed as you stated.