If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

You only need to create the small backup once for a given software version. There's no reason why each aspiring hacker needs to make their own.

You only need to create the small backup once for a given software version. There's no reason why each aspiring hacker needs to make their own.

With the increasing difficulty in finding backups these days, not to mention what kind of condition they are going to be in when you get them, hacked, not hacked, if the FS has been messed with, etc. it would be extremely handy for people to be able to create their own. Personally, I won't use a random image on emule or whatever. I don't know who it came from or what they've done to it. Now if it were alldeadhomiez tiny tivo 4.x or whatever, someone I would trust, I may use an image. But that puts the trusted party at liability for distributing tivo images.

Then you get into things like hardware revision. For anything that calls home, you would really need to have that part right. I think those are all good reasons why someone may need to create their own.

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

Neither do I. The auto rehack just restores bash, tivoweb, etc. Patching tivoapp is still a manual process. The whole idea is for people that know nothing about tivo hacking and just want cool features like tivoweb, yac, elseed, etc. My parents fall into that category. For others that do more with their tivos, like extraction, they can still go in behind the upgrade and patch tivoapp. The scripts can decide if the new partition becomes active or not as a config setting.

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

That's an interesting idea. But I think 32 megs may be cutting var a little close. Slices alone would take up a large part of that during an upgrade, plus you add in the space tmp needs, and whatever is in log. Var may fill during an upgrade and cause a nightly reboot/upgrade loop.

Now that we can monte from 2.4.18 and 2.4.20 (link), the recommended killhdinitrd'd kernel to use for a monte setup could change. I know that the 3.1.1c kernel has been recommended because it will boot on all TiVo hardware. Anybody know about hardware compatability of the 3.1.5 kernel? Might it make sense to recommend 3.1.5 and the 2.4.20 version of kmonte.o now? The main advantage is that it has lba48 support, so the kernel you monte to could live above the lba28 mark.

Another possibility is to use a kernel that matches your tivo software, then monte from that. For example, with TiVo software 4.0.1b, you can use the 4.0.1a killhdinitrd'd kernel. This also allows people to move to monte from a standard killhdinitrd setup without changing their initial boot kernel. If you need to monte (for example, to use the s2_unscramble stuff), you can do it from your standard kernel. If the monte fail for some reason, you're still in a kernel that can bring up myworld.

Now that we can monte from 2.4.18 and 2.4.20 (link), the recommended killhdinitrd'd kernel to use for a monte setup could change. I know that the 3.1.1c kernel has been recommended because it will boot on all TiVo hardware. Anybody know about hardware compatability of the 3.1.5 kernel? Might it make sense to recommend 3.1.5 and the 2.4.20 version of kmonte.o now? The main advantage is that it has lba48 support, so the kernel you monte to could live above the lba28 mark.

Have you run into any problems booting 2.4.20/3.1.5 and monteing into 2.4.18 or 2.4.4? IIRC that has triggered exceptions for me, which I could not trace back to problems with monte-mips.

Have you run into any problems booting 2.4.20/3.1.5 and monteing into 2.4.18 or 2.4.4? IIRC that has triggered exceptions for me, which I could not trace back to problems with monte-mips.

Haven't noticed that, but I'm not using this "in production" yet, and it's possible I didn't test that case. I think I went from 2.4.4->2.4.18->2.4.20->2.4.4 and all worked, but I might be remembering wrong. I'll try tonight. It's possible that 2.4.20 initializes the hardware in a way that confuses 2.4.18 and 2.4.4.

Haven't noticed that, but I'm not using this "in production" yet, and it's possible I didn't test that case. I think I went from 2.4.4->2.4.18->2.4.20->2.4.4 and all worked, but I might be remembering wrong. I'll try tonight. It's possible that 2.4.20 initializes the hardware in a way that confuses 2.4.18 and 2.4.4.

Tonight I tested cold boot monte's from 2.4.20 to 2.4.4 and 2.4.18 and from 2.4.18 to 2.4.4 and 2.4.20. All worked without error on my hardware (24008A S2SA).

It is advisable to unload all other modules before the monte. I did have problems if I had the usb modules loaded when I monted.

I'm chasing the holy grail of being able to hack and never having to remove the drive again (barring drive failure).

I haven't had to pull a drive in quite a while. The trick, for me anyway, is to always be sure to have a working minimal boot setup in the alternate partition (rc.sysinit that just runs bash on the console.) If you screw up the main root, just toggle to the alternate from the PROM menu and boot up your minimal environment for repair.