(DEPRECATED) SLEEPER ISO - Series 2 Scripts for U5, Monte and Prom with many hacks

[Mighty LoPan]

Originally posted by NutKase
What does the port###.log in the mfs_ftp directory say?
NutKase

Strangely, I don't have that file on my system, as far as I can tell, anyway. I was looking for that file earlier, and I couldn't find it. I really don't know what to make of that...

However, after trying a bunch of times to grab a file, it started working. It doesn't seem to make any sense, since I haven't changed anything...but I'm not going to look a gift horse in the mouth.

[Spydertech]

ok now that i got this thing working
i have a few questions
in other how-to's there is a file called (hackinit) with this script what is this file called?
(rc.sysinit.author or rc.sysinit)?

The hacks are placed in a file called rc.sysinit.author
This file is located in /etc/rc.d

[vertex]

i guess you could say rc.sysinit.author replaces the hackinit file. or you could make a hackinit file and call it from rc.sysinit.author.

[NutKase]

Originally posted by vertex
i guess you could say rc.sysinit.author replaces the hackinit file. or you could make a hackinit file and call it from rc.sysinit.author.

hackinit or rc.sysinit.author - depends on which 'guide' or script you're using.

Or you could make a

domystuff.now

file and call it from anywhere.

rc.sysinit.author just happens to be automatically called from rc.sysinit which 'launches' your tivo.

Just edit the lines at the end of rc.sysinit to point to wherever and whatever you want. rc.sysinit.author is the normal filename and keeps everything standardized

NutKase

[Sleeper]

Originally posted by vertex
i guess you could say rc.sysinit.author replaces the hackinit file. or you could make a hackinit file and call it from rc.sysinit.author.

Actually, hackinit is just what the name implies - a hack way to init your hacks.

/etc/rc.d/rc.sysinit.author is the more correct location/name for the file. On the older U5 howto, the file was commonly called hackinit, but could be called anything as was pointed out.

The file could not be located in /etc/rc.d with the U5 hack because it would be deleted by the u5 rc.sysinit which is run upon boot. With monte & prom, the initrd is removed from the kernel image and the file system is not checked, thereby allowing the correct file to be located in the correct place. rc.sysinit.author is run upon completion of rc.sysinit, which is run as part of the linux boot process. So nothing special has to be done to get it to run, unlike the u5 hack.

[Sleeper]

Originally posted by Mighty LoPan
Good idea! Thanks for the help. I can see from searching that you're a big fan of this tool. Is it commonly used? I've never heard of it, but then I don't work on network code.

tcpdump is an excellent tool. Great way to see those nasty little viruses try to talk to random IP addresses and try to spread themselves. You don't have to run it on your tivo - any machine on your network can sniff traffic. However, you want ot make sure that you are using a hub and not an ether-switch or else you will not see all the trafic on the network.

[NutKase]

Originally posted by Sleeper
The file could not be located in /etc/rc.d with the U5 hack because it would be deleted by the u5 rc.sysinit which is run upon boot.

A more precise answer, and I learned more myself, Thanks.

NutKase

[superg]

First off, Thanks for the great ISO for monte. Damn nice job you did there.

Now to my question. I have monte set up on 3.1.0 and it works perfect, but i would like to let it update to 3.1.1b while still enjoying the hacks.

I have read and read and can't seem to get my answer. I know the softwareupgrade=false is in the bootpage, but where is the bootpage and can it be edited from bash?

Thanks
superg

[Sleeper]

Originally posted by superg
Now to my question. I have monte set up on 3.1.0 and it works perfect, but i would like to let it update to 3.1.1b while still enjoying the hacks.

Thanks!

Well that's not going to be that easy. If you removed the upgradesoftware=false then that would allow an upgrade.

However, the upgrade process is going to flip the bootpage (bootpage -f).

This will cause the tivo to try to boot your 3.1.0 kernel that is currently monte'd. It will not be able to boot because the kernel has it's initrd removed and will not pass the kernel signing check done by the prom.

To fix this you will have to install the drive in your pc. Boot from the cd and flip the bootpage again /cdrom/bootpage -f /dev/hdc

I'm not certain how the upgrade process handles the old bootpage. You many also have to manually write the bootpage: /cdrom/bootpage -P root=/dev/hdaX -C /dev/hdc

"X" will be 4 or 7

Once you have the upgrade installed, you will have to run the scripts to reinstall monte & hacks.

If you have your original drive you may want to install it and force an upgrade. Then run the scripts and restore to your new drive. You will loose your recordings.

[ArizonaTea]

Sleeper, thanks for the script. It works great! I ran it the first time and everything worked perfect. Just have one recommendation...

I currently have 3.1.0 and have no plans to upgrade to another version at all. I would like to actually use the original Bash_ENV method to avoid having all the extra code required for the Monte Method(And maybe improve boot up time just a bit). Would it be too difficult to include the original Bash_ENV method in the next version of the script as one of the options in the main menu?

That would greatly be appreciated if it's not too much work for you.

Thanks,
ArizonaTea

[vertex]

why not just use the monte and not upgrade the monted version. it makes it alot easier being able to place your hacks anywhere you chose on the monted OS.

Originally posted by ArizonaTea
Sleeper, thanks for the script. It works great! I ran it the first time and everything worked perfect. Just have one recommendation...

I currently have 3.1.0 and have no plans to upgrade to another version at all. I would like to actually use the original Bash_ENV method to avoid having all the extra code required for the Monte Method(And maybe improve boot up time just a bit). Would it be too difficult to include the original Bash_ENV method in the next version of the script as one of the options in the main menu?

That would greatly be appreciated if it's not too much work for you.

Thanks,
ArizonaTea

[captain_video]

I currently have 3.1.0 and have no plans to upgrade to another version at all. I would like to actually use the original Bash_ENV method to avoid having all the extra code required for the Monte Method(And maybe improve boot up time just a bit). Would it be too difficult to include the original Bash_ENV method in the next version of the script as one of the options in the main menu?

The BASH_ENV hack is completely different from the monte hack and is covered in cobelli's guide and Ingineer's original hack. It's also the preferred method of hacking a series 2 Tivo. Rather than ask someone else to do the work for you why not take the time to learn how to do it yourself? The amount of extra code for the monte hack doesn't amount to a hill of beans if you think you're going to save any hard disk space. The BASH_ENV hack also doesn't make your Tivo boot any faster than the monte hack.

[David Bought]

Originally posted by captain_video
The BASH_ENV hack also doesn't make your Tivo boot any faster than the monte hack.

1) The monte hack in its most common setup depends on the BASH_ENV hack.

2) Wrong. The monte hack slows down the boot process by a few seconds as it loads and boots a second kernel. You can see this by watching the serial port.

If you didn't know this, stop now and learn before you continue posting. If you did know this, quit oversimplifying things because you are not doing anybody any favors. The fact of the matter is that monte requires a previously compromised system and only facilitates the use of a non-3.1u5 (or non-2.0.3) kernel.

[Sleeper]

Originally posted by ArizonaTea
I currently have 3.1.0 and have no plans to upgrade to another version at all. I would like to actually use the original Bash_ENV method to avoid having all the extra code required for the Monte Method

That script was originally included in the pre-release. However, I removed it because I could no longer justify it. I do not believe that your statements have merrit.

(And maybe improve boot up time just a bit).

For the sake of others - I do not want to turn this thread into an argument. I would be happy to start another thread on this topic. I use a slightly modified version of alldeadhomiez' minimal file system. I believe that the time it takes the U5 kernel to boot and check the MINIMAL file system and then boot the other kernel which performs no file system check is LESS than the time that it takes the stock image to boot.

Would it be too difficult to include the original Bash_ENV method in the next version of the script as one of the options in the main menu?

No it would not be difficult. However, it is a matter of justification, support and demand. Right now I don't see the need.

Thanks for your comments.

[Mighty LoPan]

But back to the real topic here. I've been thinking about the advantage and disadvantage of Sleeper's ISO. It's easy to use, however, it also means that people will have a custom setup without having any idea of how it works. Don't get me wrong, it's a great system, but I think it would be nice to have more of a tutorial feel to it as an option for those who want to know why things are set up as they are. It could explain things like what the rc.sysinit.author file is and when it gets executed - just little hints to put people on the right track towards understanding how it all hangs together.

EDIT: I just noticed that captain_video had a similar idea a few pages back.