Page 1 of 2 12 LastLast
Results 1 to 15 of 21

Thread: Modular inline monte configuration - request for comments (RFC)

  1. #1
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829

    Modular inline monte configuration - request for comments (RFC)

    As our killhdinitrd exploitable kernels begin to go out of date, and/or we want to start patching our kernels (for some net speed increases for example,) it'll become necessary to either hack the prom or chainload kernels in order to move forward.

    The good thing about killhdinitrd kernels vs bash_env kernels is that we no longer need a two partition configuration for monte - instead we can do an inline configuration which only requires one partition and makes things nowhere near as complicated. (no more romfs, no more bothering with simultaneous dual root configs)

    I've done this with my own tivo, and basically designed an algorithm that follows:

    -Boot a killhdinitrd'ed 3.1.1c kernel (this one boots with any S2 hardware, save for the S2.5 units)

    -/test.conf contains the following:
    Code:
    #!/bin/bash
    [ ! -f /chainload/check.sh ] || /chainload/check.sh
    (note test.conf is like rc.sysinit.author, only it gets executed at the very beginning of the init stage as opposed to the very end)

    -/chainload/check.sh contains the following:
    Code:
    #!/bin/bash
    
    if [ "$chainloaded" != "1" ] ; then
        echo "Running monte."
        /sbin/insmod -f /chainload/kmonte.o
        /chainload/monte /chainload/vmlinux.px root=$root console=2,115200 dsscon=true runideturbo=false upgradesoftware=false chainloaded=1
    else
        echo "Chainloaded environment in place, skipping monte."
    fi
    In a nutshell, when your tivo boots up it checks to see if you have a chainload configuration defined, and if so it runs it. The chainload script checks if a 'chainloaded=1' environment variable is set. If not, it executes monte and chainloads a new kernel, setting the chainloaded=1 variable in the process. When the reset occurs, the new kernel boots up and the chainload script will see the chainloaded=1 variable ignoring monte and running your regular init scripts (thus not going into an infinite chainloading spree.)

    This is a pretty modular configuration. Anytime an upgrade occurs, all you have to do is load the 311c kernel to the alt boot (or even both kernel partitions if you'd like, just to be safe) and do the usual copying over of the init scripts and other dirs, only this time include the chainload dir as well. Theres never any need to adjust the config scripts nor the bootpage outside of what the regular upgrade process already does on its own automatically. If you change major software versions, be sure to compile a new kernel and replace the /chainload/vmlinux.px with it. Also, unlike the previous bash_env monte method, tigers mfstools will definitely be able to backup this configuration without doing any tricks.

    EDIT: Updated to include suggestion by JohnSorTivo.
    Last edited by AlphaWolf; 03-17-2005 at 06:33 AM.
    Before PMing me: I知 not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  2. #2
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Maybe this isn't as eloquent since it is a 2 step process, but, in order to try and be kernel independent, why not just set the initial bootpage parameters to include a run monte variable, i.e:

    bootpage -P "root=/dev/hdaX dsscon=true console=2,115200 upgradesoftware=false monte=1" /dev/hda

    And then, in check.sh:

    Code:
    #!/bin/bash
    
    if [ "$monte" == "1" ] ; then
        echo "Running monte."
        /sbin/insmod -f /chainload/kmonte.o
        /chainload/monte /chainload/vmlinux.px root=$root console=2,115200 dsscon=true runideturbo=false upgradesoftware=false monte=0
    else
        echo "non killhdinitrd kernel loaded, skipping monte."
    fi
    This way, there is no need to check for a specific kernel version, and it makes the script more universal. I certainly realize it's just as easy (maybe easier) to plug-in the correct values for the kernel you have run killhdinitrd against for your kcheck variable, but just a thought.

    Or, without revising the bootpage parameters, just checking for the reverse:

    Code:
    #!/bin/bash
    
    if [ "$monte" != "0" ] ; then
        echo "Running monte."
        /sbin/insmod -f /chainload/kmonte.o
        /chainload/monte /chainload/vmlinux.px root=$root console=2,115200 dsscon=true runideturbo=false upgradesoftware=false monte=0
    else
        echo "non killhdinitrd kernel loaded, skipping monte."
    fi
    EDIT: I guess, now that I look at this, what I've suggested is really no different that what they are already doing using the rc.sysinit.bogus file
    Last edited by JohnSorTivo; 11-10-2004 at 02:58 PM.
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  3. #3
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    Ah, I totally forgot about the kernel params being adjustable by monte when I first thought this up, that is a good idea. In fact, we can just not even touch the bootpage, and thus also skip the kernel version check completely.

    Code:
    #!/bin/bash
    
    if [ "$chainloaded" != "1" ] ; then
        echo "Running monte."
        /sbin/insmod -f /chainload/kmonte.o
        /chainload/monte /chainload/vmlinux.px root=$root console=2,115200 dsscon=true runideturbo=false upgradesoftware=false chainloaded=1
    else
        echo "Chainloaded environment in place, skipping monte."
    fi
    When your system boots up, the 'chainloaded' variable wont ever be set. Once this script runs through, it'll load the new kernel, only this time with the chainloaded environment variable now set which will survive through monte's system reset. When your tivo does a full reboot though, naturally it'll be unset, running through monte again.

    EDIT: Oops, thats what you just said Should have read your post completely before responding.

    EDIT2: Just realized bash doesn't like the logic I used...adjusting.
    Last edited by AlphaWolf; 11-11-2004 at 02:08 AM.
    Before PMing me: I知 not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  4. #4
    Join Date
    Sep 2001
    Location
    West of Bermuda
    Posts
    1,017
    you need to reverse the meanings of the bootparam switches. we know that some of the newer kernels are checking for "foreign" values in the params, so it's better to assume the need to monte if "monte=1" is *not* set, then set it upon monte to indicated that you've already done it.

    ronny

  5. #5
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    My thoughts exactly.
    Before PMing me: I知 not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  6. #6
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by ronnythunder
    you need to reverse the meanings of the bootparam switches. we know that some of the newer kernels are checking for "foreign" values in the params, so it's better to assume the need to monte if "monte=1" is *not* set, then set it upon monte to indicated that you've already done it.

    ronny
    Yup, as you'll see in my initial post, as I was typing, I realized this, and included a second "version" which did the reverse, as you have suggested, and as AlphaWolf also arrived at just after.

    Thanks.
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  7. #7
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    AlphaWolf,

    Just noticed a small error in the first post instructions that would likely cause an individual's system to not boot successfully.

    The example shows test.conf being placed in the /etc/rc.d/ directory:

    Quote Originally Posted by AlphaWolf
    -/etc/rc.d/test.conf contains the following:
    Code:
    #!/bin/bash
    [ ! -f /chainload/check.sh ] || /chainload/check.sh
    However, a quick peek at the default rc.sysinit file shows a call to test.conf as follows:

    Code:
    [ ! -f /test.conf ] || source /test.conf
    Which, as you can see, is expecting test.conf to be in the root directory, as opposed to /etc/rc.d.

    John
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  8. #8
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    Hmm....mine seems to work fine in the /etc/rc.d directory. Course my /etc/rc.d/StageA_PreKickstart/rc.Sequence_000.SourceLocalConf.sh script does this:

    Code:
    for ConfFile in /etc/rc.d/*.conf /test.conf ; do
        [ ! -f $ConfFile ] || source $ConfFile
    done
    This is a 5.x configuration. 4.x will probably be the same, dunno about 3.x though.
    Before PMing me: I知 not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  9. #9
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by AlphaWolf
    Hmm....mine seems to work fine in the /etc/rc.d directory. Course my /etc/rc.d/StageA_PreKickstart/rc.Sequence_000.SourceLocalConf.sh script does this:

    Code:
    for ConfFile in /etc/rc.d/*.conf /test.conf ; do
        [ ! -f $ConfFile ] || source $ConfFile
    done
    This is a 5.x configuration. 4.x will probably be the same, dunno about 3.x though.
    Interesting. I was speaking from experience on this one, as last night, I grabbed a 200GB Seagate I had lying around, and for fun, decided to install 4.0 with an lba48 kernel, etc, on my HDVR2. I used the 'inline' approach as described above, and it wouldn't boot. My kernel logs showed some 'conflicting kernel' messages, which lead me to believe that my 2.4.18 lba48 kernel wasn't getting chainloaded sucessfully (my boot kernel is a killhdinitrd 3.1.1c/2.4.4), and as such, it appeared that test.conf wasn't getting run.

    Poked around and saw the above referenced in rc.sysinit, and as such, I moved test.conf to my root directory, rebooted, and everything came up without issue.

    I don't have/see a file which loops through /etc/rc.d/ looking for *.conf, such as etc/rc.d/StageA_PreKickstart/rc.Sequence_000.SourceLocalConf.sh on my system.
    Last edited by JohnSorTivo; 11-13-2004 at 10:35 AM.
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  10. #10
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    Well, might just be 5.x then.
    Before PMing me: I知 not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  11. #11
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by AlphaWolf
    Well, might just be 5.x then.
    That's cool. Just wanted to document what I found with my version, so that if others use this approach, that they realize they may have to make a few adjustments, by either moving 'test.conf' or altering rc.sysinit to point to the correct location, again, if necessary, YMMV.
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  12. #12
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    This is very good. Elegant in its simplicity!

    One thing I do not understand. Given the config you just described, you are calling a 4.01b program (/sbin/insmod) which should need at 2.4.18 kernel, with a 2.4.4 kernel (which 3.1.1c uses). That should not work, should it? Don't you also need a small bin of 3.1.1c compatible utilities for the intial boot? Or am I missing something?
    Last edited by blueman2; 11-20-2004 at 12:24 AM.

  13. #13
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by blueman2
    This is very good. Elegant in its simplicity!

    One thing I do not understand. Given the config you just described, you are calling a 4.01b program (/sbin/insmod) which should need at 2.4.18 kernel, with a 2.4.4 kernel (which 3.1.1c uses). That should not work, should it? Don't you also need a small bin of 3.1.1c compatible utilities for the intial boot? Or am I missing something?
    Insmod is a linux bin, not a 4.x bin, or a 3.1.x bin, it's always a mips processor, so it works, regardless of the Tivo software version. Perhaps I'm not understanding your question correctly?
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  14. #14
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    You answered it. I thought all programs were dependent on specific kernels to work. E.g. I though you needed to have a 2.4.18 kernel booted to run programs in a 4.01b /sbin directory because all 4.01b programs were compiled using a 2.4.18 kernel, right? Just like in the old DOS world, if you tried running a fdisk or format bins from a 3.3 OS disk on a 3.1 booted system, it would not work. But it sounds like some programs, such as insmod, are independent of which kernel is booted?
    Last edited by blueman2; 11-20-2004 at 02:28 PM.

  15. #15
    Join Date
    Mar 2004
    Posts
    77
    OK, I'm pretty much a noob, but here goes. I have a tdc240xx, hacked for about a year, using killhdinitrd, with mfs_ftp, tserver, bufferhack, and more goodies. Now Tivo has seen fit to send me the 7.1 upgrade, which I have kept from being installed with upgradesoftware=false. I've been playing around with a spare drive, letting it take the upgrade. I'd like to use your inline monte configuration, set it up as per your post. I dd the 3.1.1c kernel to partitions 3 and 6, created test.conf in rc.d, and set up the chainload directory with the monte files, the check.sh file, and a kernel I extracted from the 7.1 install with dd if=/dev/hdc3 of=mypath/vmlinux.px. When I start up the tivo I get this in the serial output

    Code:
    Primary data cache 32kb, linesize 32 bytes.
    Linux version 2.4.4-TiVo-3.0 (build@buildmaster10) (gcc version 3.0) #9 Wed Jan
    and further on

    Code:
    Starting rc.sysinit
    Running boot Stage A_PreKickstart scripts
    Scanning for configuration files
    RUNNING MONTE.
    monte: Two-kernel Monte for MIPS (Version 0.1)
    monte: MuscleNerd (MIPS version), Erik Arjan Hendriks (x86 version)
    monte: loaded kernel image (target load_addr=0x80001fe0, len=0x1db0af) at 0x8167
    3fe0
    monte: total pages used: 478 for image, 2 for indirect tables, 1 for reload code
    This is followed by a long pause, then a reboot, where my new files get wiped out, and the tivo goes into a continuous reboot loop.
    Any ideas on where I'm going wrong? I'd like to get to where I can start experimenting with different hacks on 7.1. I'd keep 4.0 but I have MRV issues with another tivo, a tdc540040 after tivo sent me the upgrades. Something to do with new keys for mrv. It would seem I need a different kernel to monte into, not sure what to use. I see that some people are having success using a killhdinitrd 3.1.5 kernel, and booting directly into 7.1. Would this be the way to go? Anyways, any suggestions would be appreciated. TIA

    Rick
    Last edited by ronrico51; 02-28-2005 at 10:08 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •