two card monte with the kernel evolves in 2004

[rc3105]

this is a continuation of the discussion in

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

and where Monte development questions / hints / tips should be posted if you're not a developer

*good rule of thumb, if you don't have a working tivo cross compiler stick to posting in the support threads


_________________________

reserved for links to a worthy thread / guide

here's a good candidate

A killhdinitrd'd 3.1u5 kernel and a Monte

_

[rc3105]

major kudos to musclenerd (patron saint of the soldering impaired) for porting monte to the tivo & sharing it


unfortunatly there have been several bad guides & an iso or three that recommend or install wacky configs that make things much more difficult than necesary

factor in some new developments and it's time to overhaul the way we get into our s2's

my personal method works pretty well, but I have way more projects than spare time to write a guide...


lets open the floor to discussion & see what develops

the first post of this thread will link to the best guide available

[Juppers]

What I have done is used tivopart to create a nice sized "safe" partition on hda1 booting from a killhdinitrd'd 3.1u5 kernel on hda2. From there, the rc.sysinit on hda1 looks at bootpage -a to see which regular partition not to monte into, then montes into the correct one. ie bootpart -a returns 6, the script takes that as hda4 should be the new root. My hacks all on hda1 are symlinked into the active root. I monte off a kernel image made from the original kernel for that partition using the replace_initrd util that is floating around. The only required changes to the stock filesystem that I am monte'ing into are the addition of my rc.sysinit.author and a modified installSw.itcl that has one extra line inserted in there to call a script to handle software upgrades. In the event of a newer software version being installed via normal tivo methods, the extra line in the installSw.itcl runs a script that copies over the rc.sysinit.author and the installSw.itcl to the new filesystem and makes a new initrd-less kernel image to monte. In theory, after the reboot, I should still have all my main hacks and only need to apply any tivoapp patches I may use, like the noscramble patch.

I would like if some of the more experienced members in setups like this would take a look at my scripts and see if I have any obvious flaws in my logic flow.

Not a guide, but an example of the new monte possibilities.

[rc3105]

one observation

it's TREMENDOUSLY handy to be able to change the boot params from the prom menu via serial

(3.1u5 bash_env + the decoy filesys can boot bash, which can mount root or var, which could load telnet/ftp to move slices or a tivo mfstool binary + image or feed it from netcat... never pull a drive again!)

near as I can tell the prom only offers 3 & 6 as kernel options so it's preferable to keep 'em therebouts

[my0gr81]

OK, first of all I posted this in Series2 development, I do not have a cross compiler set up or have any programming aspiration. I can follow source but don't ask me to write my own, just not enough inspiration there.

Here is link:
tivomaster's remote panic code thread

We can combine the two together to form the basis of a SA S2 TIVO that can boot a normal killhdinitrd'd kernel (2.4.18) for SA S2, monte a LBA48 (2.4.20) aware kernel pointed to the usual root under normal boot and pivot_root to an alternate root for recovery purposes in case one of the hacks didn't work and hosed the system. This would also be handy to trap the software update process before it even got started to give us time to back up the slices and decide how to handle the update without killing the hacks and the partitions set up. The alternate root could be the one holding the files system for the monte so as to not waste yet another partition.

I am still learnign about pivot_root myself.

[NutKase]

Originally Posted by rc3105

one observation

it's TREMENDOUSLY handy to be able to change the boot params from the prom menu via serial

(3.1u5 bash_env + the decoy filesys can boot bash, which can mount root or var, which could load telnet/ftp to move slices or a tivo mfstool binary + image or feed it from netcat... never pull a drive again!)

near as I can tell the prom only offers 3 & 6 as kernel options so it's preferable to keep 'em therebouts

CRAP! I just started a new thread about my new killhdinitrd monte experiences.

This is where I'm trying to go (thanks to you rc3105)

[UPDATE]
Total success!

NutKase

[rc3105]

lol, plenty of room for different takes on the same issues

feel free to work up a guide, I'm currently preoccupied with getting ota-hd to play/burn consistantly on the 810...

edit: if you don't have a pile of 21" monitors laying around with hdtv adapter cables (I do) this is a sweet deal. not a bad monitor either with the right video card

[Juppers]

Originally Posted by rc3105

one observation

it's TREMENDOUSLY handy to be able to change the boot params from the prom menu via serial

(3.1u5 bash_env + the decoy filesys can boot bash, which can mount root or var, which could load telnet/ftp to move slices or a tivo mfstool binary + image or feed it from netcat... never pull a drive again!)

near as I can tell the prom only offers 3 & 6 as kernel options so it's preferable to keep 'em therebouts

I don't see how that offers any benefit over the method I used. If I need to do fs work like that, I can add a boot param from the prom menu that prevents the monte and drops me into my safe FS. The bootable partition never needs to be changed, just what happens as the unit boots. Scripts on the safe partition should decide what boots, and the original tivo files on 3/4 6/7 are unchanged aside from installSw.Itcl and an added rc.sysinit.author. The stock upgrade process doesn't need any fiddling with, aside from the addition in installSw.itcl that calls a script to auto rehack the new software and reset the boot and alternate partitions.

Whichever method someone chooses, the only hard part is changing the partition sizes to give you room to put things in 1/2/5. How do you do that on a stock drive without rebuilding your MFS from scratch? Tivopart is really handy for upgraded systems, although probably needs to be rethought to make 5 the large paritition instead of 1.

[alldeadhomiez]

Originally Posted by Juppers

Whichever method someone chooses, the only hard part is changing the partition sizes to give you room to put things in 1/2/5. How do you do that on a stock drive without rebuilding your MFS from scratch?

I've been allocating 1GB+ swap partitions for a long time when imaging, so that I have room to grow.

If people would take the time to learn how to do things correctly, the images floating around would be "micro" images which are significantly smaller and work on <40GB drives. A properly constructed stock 4.0 image should be about 65MB. Most backups I have seen are 150-300MB or larger.

Tivopart is really handy for upgraded systems, although probably needs to be rethought to make 5 the large paritition instead of 1.

I used to use hda2 and hda5 for the 3.1.U5 kernel and decoy root.

I am thinking of using hda2 for the main root, and hda5 for the main /var in the next revision. This would allow my scripts, Debian root, and such to work independent of any faults that occur in the TiVo subsystem.

tivopart was designed in such a way that repartitioning never requires that you reimage or backup/restore the MFS, so recordings and user settings are preserved.

[rc3105]

just shrink var a bit. expanding 2,3,5,6 from 2 to 4 eats 8 meg tops

even if you insist on using a stock drive I'd recommend bumping swap from 64 to 127. var is perfectly usable at 57 meg


both can be done in the tivo w/o pulling the drive. takes a reboot or two & a lil forethought but it's not rocket surgery

[Juppers]

Originally Posted by alldeadhomiez

I've been allocating 1GB+ swap partitions for a long time when imaging, so that I have room to grow.

If people would take the time to learn how to do things correctly, the images floating around would be "micro" images which are significantly smaller and work on <40GB drives. A properly constructed stock 4.0 image should be about 65MB. Most backups I have seen are 150-300MB or larger.

I've been around a long time, and I have no idea how to do that. You have a grasp of the filesystem that the majority of the people here just don't. I recently tried to create a small fs like you had outlined, and couldn't even get the loopsets to extract on a 5.1.1b SD-H400.

tivopart was designed in such a way that repartitioning never requires that you reimage or backup/restore the MFS, so recordings and user settings are preserved.

As long as you had the foresight to make a large /var at some point.

[Juppers]

Originally Posted by rc3105

just shrink var a bit. expanding 2,3,5,6 from 2 to 4 eats 8 meg tops

even if you insist on using a stock drive I'd recommend bumping swap from 64 to 127. var is perfectly usable at 57 meg


both can be done in the tivo w/o pulling the drive. takes a reboot or two & a lil forethought but it's not rocket surgery

4 megs is fine for just a monte setup, but if you want to keep your hacks and scripts out of harms way, you will need something larger than that. While we know how the tivo software upgrades work now, at any point they could add a installsw.itcl in the utils package and overwite 4/7. While you may be able to still have bash, it would be alot easier if you still had all your files safe on another partition.

[alldeadhomiez]

Originally Posted by Juppers

I've been around a long time, and I have no idea how to do that. You have a grasp of the filesystem that the majority of the people here just don't. I recently tried to create a small fs like you had outlined, and couldn't even get the loopsets to extract on a 5.1.1b SD-H400.

I can't guarantee that anything works right on 5.x.

The scripts might be a little buggy but the concept is simple.

I've seen pdfs of the programming chapter from the Keegan book floating around on eMule. Most of what you need to know is in there. But kids, don't steal that book because it's wrong and immoral and Jeff spent a lot of time writing it. To buy the book legit and give Jeff his Amazon commission, click here.

As long as you had the foresight to make a large /var at some point.

Right, the idea is to leave yourself extra space in case it's needed someday.

[Juppers]

Originally Posted by alldeadhomiez

I can't guarantee that anything works right on 5.x.

The scripts might be a little buggy but the concept is simple.

I've seen pdfs of the programming chapter from the Keegan book floating around on eMule. Most of what you need to know is in there.

Right, the idea is to leave yourself extra space in case it's needed someday.

But without the ability to create "small" backups, you can't leave yourself extra space in case it is needed someday while using a stock drive. While if I fiddle with it long enough I'm sure I can create a small backup, the majority of the people here probably wouldn't be able to do the same. If expanding partitions is the direction the post killhdinitrd monte is going, it doesn't do any good if only a small percentage of the people here can figure out how to do it, unless they had added storage space. Not everyone upgrades the drive space.

[rc3105]

Originally Posted by Juppers

4 megs is fine for just a monte setup, but if you want to keep your hacks and scripts out of harms way, you will need something larger than that.

I like to get everything down where it fits in root, then clone the active partition set to the inactive set. an upgrade will clobber the inactive set and leave my mods intact on the newly inactive set until I get around to messing with it

auto-upgrade + hack is a nice idea, but I wouldn't trust any such script to match tivoapp patch locations for noscramble 'n all

if you're restoring to a larger drive (or using a adh style micro image) you can create the debian/hack/whatever partition out in apple free space above partition 15, then use pdisk to simply swap the numbers between say 1 & 17. the partition table might look odd listed by sector number but unless you try to keep your lba48 kernel there it's not a problem


edit:

juppers, if you delete var & partition 1 you can carve 2 new partitions out of the free space. then renumber the former partition 1 (now apple free space) out to the end of the drive & assign one of the new partitions to hda1. that way you could shrink var to say 32 meg & use the other 96 for hda1-hacks even on a stock drive