two card monte with the kernel evolves in 2004

[rc3105]

nope. create a small ramdisk, chroot, have your way with the drive. don't forget to rebuild the kernel, root + partition table before rebooting. ( as easy as "dd if=base_config.dd of=/dev/hda" ) if not using a mfstool image based process. don't need a ramdisk if there's any sort of hd/cd/usb storage avail

[BTUxNine]

That's a good way to be able to completely reimage a tivo without pulling the drive, and thanx for the info, but I was referring to upgrades... being able to keep up with the latest software versions without it being a major headache to get all your hacks back in place (and, of course, not losing your shows, SPs, etc).

[PlainBill]

That's a good way to be able to completely reimage a tivo without pulling the drive, and thanx for the info, but I was referring to upgrades... being able to keep up with the latest software versions without it being a major headache to get all your hacks back in place (and, of course, not losing your shows, SPs, etc).

It depends on your definition of 'major headache', and how urgently you want to go to the latest software.

I have a directory in /var which contains the files necessary to hack the system - it's small, less than 5 meg of files. I have a similar folder on my computer, and on the computer I use to hack TiVos. As I notice new versions of the utilities becoming available they are transfered to the folder on my computer, and to the folders on the TiVos as I decide to update each system to the latest and greatest. Of course, each system has 'upgradesoftware=false' set in the boot parameters.

When a new software version AND all necessary hacks become available I make sure the master folder on my computer is current, update the directory on the 'test' TiVo with the latest, and make any changes necessary to intercept the reboot in installSw.itcl. It then becomes a matter of running installSw.itcl, replacing the new kernel, mounting the new root partition, and installing all the hacks, then rebooting.

Once all files have been gathered on my computer, the actual upgrade and rehack takes less than half an hour. Since the 'test' DirecTiVo is beside my computer desk, monitoring the reboot with the serial cable is easy, and if necessary, even pulling the drive to fix what I screwed up is easy. By the time I upgrade the system 'she who must be obeyed' watches, the process goes without a hitch.

PlainBill

[BTUxNine]

Sounds like you've got a good system there, but you have to admit a few things:
1) You're more knowledgable than the average person here
2) You've done these things many more times, which makes it much easier
3) Many/most people here don't have the same type of multiple-tivo mirrorable setup

Also, it's that step "installing all the hacks" that would throw many people, because mods are often made on the tivo, and may have been quite a while ago.

The bottom line is, it works very well for you, but many people would find a lot of stumbling blocks in your upgrade process, and it would probably take considerably longer... So, I'm working on a more general-use solution.

I realize that most of the hard-core hackers have their own systems in place which work well for them, but no single setup is optimal for everybody.

[PlainBill]

Sounds like you've got a good system there, but you have to admit a few things:
1) You're more knowledgable than the average person here

Certainly, if you include those who purchased 'pre hacked' DirecTiVos, followed a guide without understanding it, or are trolling. In case there is any doubt, I'm not including you in that group. I certainly have much less knowledge that JJBliss, RC3105, AlphaWolf, Alldeadhomiez, Jamie, PSXboy, NutKase, and dozens more who contribute to the forums.

2) You've done these things many more times, which makes it much easier

True, repetion tends to make things easier. However, keeping things simple also makes it easier.

3) Many/most people here don't have the same type of multiple-tivo mirrorable setup

Irelavent. In general, I have by best success and the longest time on the first try because I'm careful to do every step. By the third system I'm working from memory - which may result in pulling a drive.

Also, it's that step "installing all the hacks" that would throw many people, because mods are often made on the tivo, and may have been quite a while ago.

The bottom line is, it works very well for you, but many people would find a lot of stumbling blocks in your upgrade process, and it would probably take considerably longer... So, I'm working on a more general-use solution.

I realize that most of the hard-core hackers have their own systems in place which work well for them, but no single setup is optimal for everybody.

Installing all the hacks can be time consuming, but by keeping the initial hacks to a bare minimum (killhdinitrd kernel, rc.sysinit.author, AW's Series 2 Binaries, enabling networking), you reduce the time required and the chance of making a mistake. By ALWAYS installing hacks where the author intended you simplify that process. And by keeping the number of directories to a minimum you speed up the process.

I can upgrade and rehack a system running 3.1.1e to 6.2 in less than half an hour. By trying to install every hack I might possibly be interested in, I can more than double that time and at least triple the chance of making a mistake. By trying to make each system unique, I could make it even more difficult.

As far as a general use solution - I wish you well. Somehow I don't think you will suceed unless you reduce it to a general use SYSTEM: Everything in specific directories, no variations in hacks or configuration, and everyone must start with a specific configuration. Are you aware the most significant problems will occur when a new software release comes out (6.2a), at which time you will have to wait until the new hacks are out, THEN upgrade your solution?

PlainBill

[BTUxNine]

From what I've seen, for major version upgrades, it takes a while for the dust to settle. For minor versions, it's usually a matter of waiting for tivoapp patch locations to be found.

As to hacks, I'm NOT proposing a specific subset, or a vanilla configuration. I'm talking about a philosophy of approaching the base hack. My feeling is that root should be treated as tivo's domain, and that alterations to root should be minimal, and mostly in the form of hooks (symlinks to the hack partition -- partition 5, not var). This localizes the dynamic content (hacks, support binaries, config, etc.) to make backup/restore easier, and puts them in a place that tivo doesn't normally touch. This makes reinstalling hacks(apps) a simple matter of hooking the new root (plus changes to hacks if there are incompatibilities in the new s/w version).

[PlainBill]

From what I've seen, for major version upgrades, it takes a while for the dust to settle. For minor versions, it's usually a matter of waiting for tivoapp patch locations to be found.

As to hacks, I'm NOT proposing a specific subset, or a vanilla configuration. I'm talking about a philosophy of approaching the base hack. My feeling is that root should be treated as tivo's domain, and that alterations to root should be minimal, and mostly in the form of hooks (symlinks to the hack partition -- partition 5, not var). This localizes the dynamic content (hacks, support binaries, config, etc.) to make backup/restore easier, and puts them in a place that tivo doesn't normally touch. This makes reinstalling hacks(apps) a simple matter of hooking the new root (plus changes to hacks if there are incompatibilities in the new s/w version).

Let's see; instead of copying files to two directories, you're going to update the files in the hack partition, copy rc.sysinit.author to /etc/rc.d on the new root, and create symlinks. Will MFStools backup and restore partition 5? If not, you have something that will be more complicated to create, use, and maintain.

I may be off base here, but I see no need to tell Alphawolf, Alldeadhomiez, RC3105 and others of an advanced skill level how to set up a TiVo drive - they've come up with a solution they are happy with. I assume the target audience would be someone who just lost all his hacks because he put them in /var. Somehow I suspect anyone who made that mistake will be overwhelmed by the task of creating a hack partition. Unlike 'Men in Black' you aren't dealing with 'The best of the best' here.

PlainBill

[BTUxNine]

Creating the hack partition would be the toughest step, true, but there are many skill levels on this forum between the tivo gurus and joe newbie, and I think there are plenty of people who would be capable of creating it with the proper information laid out.

Just look at the number of posts that talk about the fact that hacks in var are problematic, and leaving root rw with no journaling is not a very good option, either. Until an updated mfstools (or similar tool) is released, any hack that involves a separate hack partition will not be able to be backed up with it, but very few people are running backups on their running tivos, anyway. (and those that do have developed other ways of doing so, in most cases)

I'm not sure why you're attacking my proposal without having any idea of the implementation, and I don't particularly want to argue with you in this manner.

[rc3105]

mfstool includes the bootstrap partition, so just resize & mke2fs it

[BTUxNine]

As I understand it, mfstools 2.0 backs up EITHER 2,3,4 or 5,6,7 depending on which set it detects as active.
This wouldn't work for my configuration (and complicates upgrades)

[rc3105]

gotta start somewhere, the bootstrap partition can contain your own kernel/scripts/utils and tag along inside a standard mfstool backup w/o modifying the "legit" kernel+root

fwiw, the mfstool source has been avail for a while now and there are several unofficial forks to add features that folks felt were lacking

[BTUxNine]

gotta start somewhere, the bootstrap partition can contain your own kernel/scripts/utils and tag along inside a standard mfstool backup w/o modifying the "legit" kernel+root

But if you follow the normal upgrade path, then when the "legit" partitition is flipped, your partition is no longer in that set. I know there are ways around this, but as it becomes more complicated, it becomes more prone to errors. Seems like a poor tradeoff when the backups are all-or-nothing (can't pull individual partitions... at least, not without a modified mfstools or a spare drive to restore to). I'd prefer to just accept, like most setups with an extra partition, that No, you can't use mfstools 2.0 to back it up.

fwiw, the mfstool source has been avail for a while now and there are several unofficial forks to add features that folks felt were lacking

I was replying to plainbill's complaint that the standard backup wouldn't work... I know there are alternatives (though it's a pity ronnythunder pulled his), but until there's a stable version that supports it, I'd just as soon backup the partitions individually.

[scotty2541]

While information is scattered all over the place (thanks to nutcase for collecting some of it in one place), I decided to build up the nerve to try a monte. My goal is to get the s2_unscramble kernel loaded.

So, How can I tell if the monte'd kernel is loaded?
What I saw in my DTV S2 6.3 version (a copied HD, not the original :-):
bootpage said root=/dev/hd4
killhdinitrc said /dev/hd3 had 'no exploit' (I think that's expected, but I'm not sure) and the crc was 130191c4 if that tells anyone what kernel was there.

What I did:
Pulled out the boot with dd if=/dev/hda3 of=/monte/vmlinux.px.hd3
(got a 4 meg file)
stuffed in a killhdinitrc kernel with dd -if=/monte/vmlinux.px -of=/dev/hda3 (a 3.1.5 kernel)
Moved rc.sysinit to rc.sysinit.real
Copied in the famous rc.sysinit.bogus and renamed it rc.sysinit

Then placed the HD back in my tivo and booted. Everything came up.

Should I have seen the message from the script:
echo "monte sysinit wrapper complete, you're on your own"
somewhere in the kernel log or message log?

I was looking for the kernel messages for the cypher keys from s2_unscramble, and didn't see them either.

So, as the subject states:
How can I know it ran the monte'd kernel?

Any advice is appreciated!
-Scotty