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

Thread: Monte from killhdinitrd 3.1.5 to S2_Unscramble

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jan 2005
    Posts
    1,008

    Monte from killhdinitrd 3.1.5 to S2_Unscramble

    ---Monte from killhdinitrd 3.1.5 to S2_Unscramble---

    I was interested in a monte from a killhdinitrd 3.1.5 to a custom s2_unscramble kernel on my Tivo 7.2.2 software release. I decided to monte my live "running" tivo (via telnet) by installing in the alternate partitions (as described by NutKase in the definitive killhdinitrd monte thread here. Note however, that NutKase was upgrading an already old-school monted tivo so his partition references probably don't apply to you; just be careful if you try to use his instructions in planning your steps.

    Why did I want to perform a monte install on my running tivo?

    1. I try to avoid pulling my drive for hacks at all costs.
    2. By utilizing the alternate partitions and enabling the boot PROM menu, I can rescue myself if I screw it up...

    So, while you're messing around in telnet do this: "crypto -u -srp <new password here>"
    This will set a new password for the PROM menu. Then, see this thread that talks about enabling booting from the prom menu (you do have a serial cable, right?)

    This is what I currently have: (6/7 are my active partitions and 3/4 are my alternate)

    /dev/hda3 (nothing)
    /dev/hda4 (nothing)
    /dev/hda6 3.1.5 killhdinitrd kernel
    /dev/hda7 7.2.2 tivo root filesystem

    What I want:

    /dev/hda3 3.1.5 killhdinitrd kernel
    /dev/hda4 7.2.2 tivo root filesystem with /monte
    /dev/hda6 3.1.5 killhdinitrd kernel (not used - alternate)
    /dev/hda7 7.2.2 tivo root filesystem (not used - alternate)

    You want to start by reading the s2_unscramble thread here.

    One word of caution - as Jamie points out in the s2_unscramble thread - the most reliable from/to kernel monte is the 2.4.4 kernel. People have had mixed results with the 2.4.18 and 2.4.20 versions of kmonte.o.

    Another important thing to remember is that you must use the proper version of kmonte.o for your kernel. It's also helpful if the kernel you are monteing from is the same as that you are monteing to (from 2.4.20 to 2.4.20) unless you need to monte to a different kernel version (for example, for LBA48 support). Oh by the way, the 2.4.20 versions of kmonte.o can be found here.

    Now I'll toss all caution into the wind and attempt the 2.4.20 kernel monte on my TCD24004A because "I just like doing things like that..."

    Telnet in and...

    1. Check my current bootpage with "bootpage -p /dev/hda"

    root=/dev/hda7 dsscon=true console=2,115200 upgradesoftware=false

    2. Mirror the 3.1.5 killhdinitrd kernel in /dev/hda3

    dd if=/dev/hda6 of=/dev/hda3

    3. Mirror the root filesystem (7.2.2) in /dev/hda4

    dd if=/dev/hda7 of=/dev/hda4

    4. mount /dev/hda4 and create /monte directory

    mount /dev/hda4 /mnt
    mkdir /mnt/monte

    5. Place the following files in /mnt/monte (ftp works well - although watch the permissions)

    monte
    kmonte.o
    vmlinux.px.3.1.5x (Custom unscramble kernel found here)
    chmod 755 "all of the above"

    6. Create rc.sysinit.monte in /mnt/etc/rc.d on /dev/hda4

    *This is basically the same as NutKase rc.sysinit.bogus (but note vmlinux.px.3.1.5x file name edit)

    Code:
    #!/bin/bash
    # bogus rc.sysinit, checks for monte
    export PATH=/sbin:/bin:/tivobin:/tvbin:.:/:/etc/rc.d
    export TERM=xterm
    export PS1='\h:\w$ '
    
    #enable this next line if you're paranoid
    #/bin/bash</dev/ttyS2&>/dev/ttyS2&
    
    #those are backticks below, not single quotes!
    bootparm=`/sbin/bootpage -p /dev/hda`
    
    if [ "$sp" != "true" ]; then
      echo "sp=\"$sp\" must be first pass, trying to run monte"
      /sbin/insmod -f /monte/kmonte.o
      /monte/monte /monte/vmlinux.px.3.1.5x "$bootparm sp=true"
    else
      echo "sp=\"$sp\" must be second pass"
      exec /etc/rc.d/rc.sysinit.real
    fi
    7. cd to /mnt/etc/rc.d and make the following file changes:

    cp rc.sysinit rc.sysinit.real
    mv rc.sysinit.monte rc.sysinit

    8. Write new bootpage params:

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

    *You don't need -C on a "live" filesystem.

    9. Flip the bootpage since you now want to boot from 3/4

    bootpage -f /dev/hda

    Check it with:

    bootpage -b /dev/hda

    Displays current boot partition as 3

    bootpage -a /dev/hda

    Displays current alternate partition as 6

    This is consistent with your bootpage parameter root=/dev/hda4 for this setup.

    10. Make sure all paths and file permissions are correct, then reboot.

    If you get into trouble, enter the PROM menu and boot the alternate (6/7) and troubleshoot.

    P.S. For the gurus, I attached my kernel log - there is a warning (line 67) in the monte load - is that a "normal" warning or something I should be concerned with? FYI - the boot completes, everything appears fine...rebooted a few times. Same bootlog, been running fine since though.
    Last edited by ScanMan; 09-25-2006 at 11:17 AM.

  2. #2
    Join Date
    Apr 2003
    Posts
    2,402
    Please explain why you need to monte from a 2.4.20 kernel if you're monteing to a 2.4.20 kernel. I think you can monte from any kernel you want as long as the kmonte.o was also complied for the same kernel you're monteing from. The big problem would be on a large hard disk where the monted-to kernel was not accessible because the monted-from kernel wasn't LBA48 aware and couldn't read past 137 GB. As long as the monted-to kernel was under that ceiling, what difference would it make what the monte-from kernel was?

    ew

  3. #3
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by ScanMan
    P.S. For the gurus, I attached my kernel log - there is a warning (line 67) in the monte load - is that a "normal" warning or something I should be concerned with? FYI - the boot completes, everything appears fine...rebooted a few times. Same bootlog, been running fine since though.
    The tainted kernel warning is nothing to worry about. ocntscha reported here that you won't get that warning if you drop the -f when you insmod kmonte.o.

    To answer EW's question: IMHO, if the tivo software you are running wants a 2.4.20 kernel, it's nicer if the monte-from kernel is also 2.4.20. That makes it easier to "comment out" the monte if you want to. Also, the tivo software can still run if the monte fails for some reason. I just wish the 2.4.20 kmonte.o worked reliably. I haven't tried it yet with the "new" killhdinitrd supported 2.4.20 kernel from 7.2.2-oth.K1.
    Last edited by Jamie; 03-31-2006 at 01:06 PM.

  4. #4
    Join Date
    Jul 2005
    Location
    San Francisco
    Posts
    134

    Thumbs up

    Jamie, is there a custom kernel for this procedure that would work on a TCD140060 like mine. I had to do a monte from 3.1.1c to your custom kernel or a replace_initrd'd kernel to hack my Tivo a few months back. For that matter, is a monte still necessary for my hardware under 7.2.2?
    Series 2 TCD140060 w/Lifetime, 9.3.2-01-2-140, 2x 250GB Seagate 7200.8 (638hrs), Monte'd, Tivotool, MRV.
    Unhacked TivoHD 500GB (76Hrs HD/638Hrs SD)

  5. #5
    Join Date
    Jan 2005
    Posts
    1,008
    I think this might answer your question...

  6. #6
    Join Date
    Jan 2006
    Posts
    26

    best 2.4.18 lba48 kernel

    Is the custom 2.4.18 kernel here, that Jamie built, still the best LBA48 kernel for 4.01b and big drives on a SA2 to monte into? I understand it has some stuff for dtivos, so thats why I'm curious. I understand it also has some network performance stuff in it too which is a plus. BTW, great work Jamie. This hobby would be nowhere without guys like you who are willing to help us noobies learn.

    Edit: Found an issue with this kernel...I have to do a ppp over serial guided setup to start out, and the first call works, but the second one in the process fails. Its like the serial port is not being released or is locked, as I see no activity on the pc/serial line during the second phase of the setup. Finally found an old kernel here that seems to work. Not sure if it has problems. I guess I will run it a while and see.
    Last edited by jbch; 09-17-2006 at 11:10 PM.

  7. #7
    Join Date
    Jan 2006
    Posts
    26
    I know this is an old request but does anybody have a pretty much stock 2.4.18 kernel for a 4.0.1b that has LBA48 support and works with the superpatch 4.x patches... Thanks.

  8. #8
    Join Date
    Dec 2001
    Posts
    78
    I just got done screwing with this all night and I realised that my welcome loop was caused by my not putting the ` (which is located next to the 1 key) instead of ' (located next to the enter key)

    simple thig to over look and can cause lots of grief.

  9. #9
    Join Date
    Jan 2005
    Posts
    1,008
    Quote Originally Posted by nakedeye View Post
    I just got done screwing with this all night and I realised that my welcome loop was caused by my not putting the ` (which is located next to the 1 key) instead of ' (located next to the enter key)

    simple thig to over look and can cause lots of grief.
    Yes, those backticks will get you every time I just added a comment to the original post...
    ScanMan --> Just another Tivo hacker...
    Killhdinitrd SA S2 Monte S2 Unscramble Upgrade Tivo Software

  10. #10
    Join Date
    Feb 2004
    Posts
    30
    In step 5 of OP how do I get my ftp (filezilla) to log into the alt filesystem to upload the necessary files. Whenever I run Filezilla, it only logs into the active filesystem (in my case, /dev/hda4)
    I had a handle on life, then it broke

  11. #11
    Join Date
    Jan 2005
    Posts
    1,008
    Quote Originally Posted by Spaceman_Spiff View Post
    In step 5 of OP how do I get my ftp (filezilla) to log into the alt filesystem to upload the necessary files. Whenever I run Filezilla, it only logs into the active filesystem (in my case, /dev/hda4)
    Well, once you have "alt" filesystem mounted (i.e., mount /dev/hda7 /mnt) then just navigate to /mnt/monte (or whatever) from your ftp client to deposit the files.
    ScanMan --> Just another Tivo hacker...
    Killhdinitrd SA S2 Monte S2 Unscramble Upgrade Tivo Software

  12. #12
    Join Date
    Feb 2004
    Posts
    30
    Quote Originally Posted by ScanMan View Post
    Well, once you have "alt" filesystem mounted (i.e., mount /dev/hda7 /mnt) then just navigate to /mnt/monte (or whatever) from your ftp client to deposit the files.
    so once I've 'mount /dev/hda7/mnt' and 'mkdir /mnt/monte' in Tera Term, anytime I transfer files with Filezilla to /mnt/monte, it is on /dev/hda7? It's a wonder I haven't blown anything up yet!

    EDIT: so I finished all the steps and have attached a log where it hung..... what did I do wrong?
    Last edited by Spaceman_Spiff; 01-17-2009 at 08:35 PM. Reason: Just thought I'd save space
    I had a handle on life, then it broke

  13. #13
    Join Date
    Jan 2005
    Posts
    1,008
    What may have happened is that when you flipped the bootpage you didn't write new bootpage parameters. So you may be booting from partition 6 but into the root filesystem at the 4th partition which is still trying to load the monte. In addition to the output of 'bootpage' also 'ls -l' your /monte and /etc/rc.d directories.
    ScanMan --> Just another Tivo hacker...
    Killhdinitrd SA S2 Monte S2 Unscramble Upgrade Tivo Software

  14. #14
    Join Date
    Feb 2004
    Posts
    30
    Firstly, I appologize for possibly being in the wrong thread. I assumed, perhaps incorrectly that because I was trying to monte with the OP steps, that I could discuss it here even though I have a 3.1.1. (2.4.4 kernel.)

    Here is what I've done. I made a truncated copy of the Tivo hard drive that is in the machine. It is a Maxtor 250G. I used MFSLive disk to boot a PC with linux and the Maxtor drive mounted as HDA. I mounted a 4GB USB key with "mount -t vfat /dev/sda1 /dos". Then to backup the Maxtor drive to the USB key I used the command:
    "backup -f 9999 -6so /dos/mybackup.bak /dev/hda"

    With that successfully copied, I then mounted a new drive (seagate 400G), and restored the file with "restore -s 128 -r 4 -xzpi /dos/mybackup.bak /dev/hda" to the Seagate drive. When I put the newly copied Seagate drive in the Tivo and boot, Tivo boots fine. I attached the log as VirginBootLog. From that boot, as seen in the log bootpage -p /dev/hda returns root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false
    Also, bootpage -b /dev/hda returns "3" and, as expected bootpage -a /dev/hda returns "6"

    Quote Originally Posted by PlainBill View Post
    One significant detail is different - a different version of kmonte.o is required.
    I am aware of this and have made sure that I have the right kmonte.o version

    Quote Originally Posted by PlainBill View Post
    I feel the first step is to determine exactly how the system came to be monted. About 5 years ago TiVoscripts (AKA Sleeper's iso) was a popular way to hack a system.
    I can't say with 100% certainty as I was not the original 'modifier' of his machine but if I had to guess I would say that Extreme 2.5 with update to 3.1.1 was used. I have sent him an email asking but he's away for 3 weeks.

    Quote Originally Posted by PlainBill View Post
    A couple of additional points. As I understand it, the unscramble kernel captures the key necessary to unscramble a recording. It does not actually unscramble it. It is used in conjunction with extraction.
    I will be using THIS process with MFS_FTP to transfer the files once the keys are being captured.

    Quote Originally Posted by PlainBill View Post
    The next point - it is not necessary to unscramble the recordings before upgrading to 6.2.
    I am assuming you are reffering to slices. I have read (not enough however) about them and they scare me. I haven't found enough information or instructions to push me over the edge from 'scared' to confident to try.

    Quote Originally Posted by PlainBill View Post
    Lastly, I am intrigued by your problems dd-ing the partitions over. That MIGHT be significant.
    Trying to be brief, here is what I CAN do. I can dd the original 3/4 to 6/7, re-write boot params with bootpage -P "root=/dev/hda7 dsscon=true console=2,115200 upgradesoftware=false" /dev/hda, flip the bootpage with bootpage -f /dev/hda and it will boot fine. I can reverse it and it will also boot fine. But as soon as I try to boot from PROM, it loses the alternate pair and I get the error message quoted in post #19 I don't understand upgrading with slices completely but I fear that there is something very wrong with the 3.1.1e and I don't want to propagate it to the new software. I'd rather start with a known, clean and stable 6.2. Perhaps, in ignorance, that is misplaced.

    I really am trying to learn how to fish, and it's with the help of the 2000+ post'ers such as yourself that the rest of us get to 'eat'. A humble and greatful 'thanks' goes out to all of 'you'

    EDIT: forgot to attach the log.....
    Last edited by Spaceman_Spiff; 01-28-2009 at 11:17 PM. Reason: cuz I'm a doofus
    I had a handle on life, then it broke

  15. #15
    Join Date
    Jan 2005
    Posts
    1,008
    As you suspected, the tivo is already monteing as you can see here:
    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=0x80002000, len=0x12d5b0) at 0x83eab000
    monte: total pages used: 303 for image, 2 for indirect tables, 1 for reload code
    You can also see the additional bootparameters that were added by the monte. By the looks of that, it appears one of the primary reasons for the monte was to enable lba48 disk addressing on older tivo software:
    Kernel command line: root=/dev/hda4 dsscon=true console=2,115200 upgradesoftware=false dsscon=true con
    sole=2,9600 upgradesoftware=false lba48=true
    So in short the monte process I outlined here won't work for you. However, with some tweaking, you may be able to load an unscramble kernel instead of the current monte-to kernel. Perhaps PlainBill can offer some suggestions on how to de-Xtreme this.

    Lastly, are you sure the recordings are still scrambled? It seems odd you have a hacked/monted/xtremed tivo and encryption wasn't disabled as part of that hacking process???
    ScanMan --> Just another Tivo hacker...
    Killhdinitrd SA S2 Monte S2 Unscramble Upgrade Tivo Software

Posting Permissions

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