Page 34 of 43 FirstFirst ... 243233343536 ... LastLast
Results 496 to 510 of 638

Thread: killhdinitrd 0.9.x Support Thread

  1. #496
    Join Date
    Aug 2005
    Posts
    7
    I haven't yet tried 3.1.5. This unit has never been hacked and I have a new drive on order that I plan to do expansion and hacks on. I'm waiting to pull my drive until the new one arrives. I'm surprised to hear the 3.1.5 kernel didn't work for you, it was my understanding that its been working in all 7.x versions so far.

    I will get back when I have some results to report.

  2. #497
    Join Date
    Mar 2006
    Posts
    1
    Quote Originally Posted by gchianes
    Sorry I was not more specific. This is the current kernel info:

    7.2.2-oth-K1
    Linux version 2.4.20 (build@buildmaster50)
    (gcc version 3.3.4) #1 Tue Feb 14 20:57:16 PST 2006

    I don't have a binary on the boot CD to generate an MD5 checksum, but I will try to get it. I suspect the checksum will be different than the one published for ver 0.9.3.

    Is it possible that since I have a HUMAX DRT400 with DVD (SN 595...) the kernel is slightly different from the ones that killhdinitrd works with?

    George
    Just to add my experience to the pile... I didn't write down my TiVo version; it was not 7.2.2-oth-K1, but 7.2.2-some-longer-string. BUT doing a strings on my boot partition gives me:

    Linux version 2.4.20 (build@buildmaster50) (gcc version 3.3.4) #1 Tue Feb 14 20:55:02 PST 2006

    which is the same same datestamp that the readme says is supported by 0.9.3. Nonetheless, I guess it is different (I also don't have a boot disk with md5/md5sum installed), since I also get "no exploit found for this kernel." Hopefully someone will release a compatible kernel image (I'd rather stick to one closer to the "default" than the 3.1.5 image), or update the source to support this one; perhaps I will when I have some hours to kill.

    -puk

  3. #498
    Join Date
    Aug 2005
    Posts
    7

    success with 7.2.2-oth.01-2-140

    My upgrade drive arrived, so here's a description of my results as promised.
    I had an unhacked S2 SA TCD240 unit that had recently updated to OS version 7.2.2-oth.01-2-140.

    Pulled the original drive and backed it up using mfstools.

    Restored and expanded the backup to my new upgrade drive.

    Installed new drive in Tivo and verified new size and that networking was still functioning.

    Pulled drive again and proceeded to modify bootpage, and copy in killhdinitrd'd 3.1.5 kernel from PTVupgrade CD.

    Copied on tivotools, and created the rc.sysinit.author file to setup telnet, ftp, bash. Also moved netfilter firewall out of the way.

    Put the drive back in the tivo and it was stuck in a reboot loop.

    Pulled the drive again and after some reading, realized that I needed to modify the iptables file.

    Put the drive back in the tivo and it booted up! DHCP didn't work as I expected so I assigned a static IP address. At first it didn't work because I assigned it 192.168.0.255. Looking into the router config, I saw that the DHCP address range was from 192.168.0.2 to 192.168.0.51. So I changed the address I assigned the tivo to 50 instead. booyah! I could telnet and ftp into the box.

    ftp'd the patched superpatch, ran it, reboot, and i can now do mrv transfers with my directivo. woohoo!

  4. #499
    Join Date
    Jan 2005
    Posts
    127
    Quote Originally Posted by puk
    Hopefully someone will release a compatible kernel image (I'd rather stick to one closer to the "default" than the 3.1.5 image), or update the source to support this one; perhaps I will when I have some hours to kill.
    The latest PTupgrade LBA48 CD "with enhancements" includes the 7.2.2-oth.K1 kernel, with killhdinitrd 0.9.3 already run on it. It's labelled version 4.03. I recommend this kernel for those running 7.x, especially on 140 hardware that otherwise must be monte'd.

    The 7.2.2-oth.K1-01-2 kernel proper is identical to the one from 7.2.2-oth.01-2. The initrd's are different, and 7.2.2-oth.01-2 doesn't seem to have a suitable jump point in the initrd, so I don't expect it will be supported.
    Last edited by 7.1; 04-01-2006 at 11:22 AM.

  5. #500
    Join Date
    Jan 2005
    Posts
    996
    Is there any significant difference b/w:

    booting from killhdinitrd 3.1.5 kernel into 7.2.2-oth.01-2 s/w

    vs.

    booting from killhdinitrd 7.2.2-oth.K1 kernel into 7.2.2-oth.01-2 s/w

  6. #501
    Join Date
    Jan 2002
    Posts
    5,601
    Quote Originally Posted by ScanMan
    Is there any significant difference b/w:

    booting from killhdinitrd 3.1.5 kernel into 7.2.2-oth.01-2 s/w

    vs.

    booting from killhdinitrd 7.2.2-oth.K1 kernel into 7.2.2-oth.01-2 s/w
    It depends on your definition of 'significant'.

    DHCP support evolved between 3.1.5 and 7.1. If you boot from a killhdinitrd 3.1.5 kernel you will have to load an additional module to obtain an IP address using dhcp. It will be seamless with a killhdinitrd 7.2.2-oth.k1 kernel.

    TCD140xxx TiVos cannot boot a killhdinitrd 3.1.5 kernel directly, the hacker must set up an in-line monte. They work fine with the killhdinitrd 7.2.2-oth.K1 kernel.

    PlainBill
    There's a difference between needing help, and just being plain ole' lazy.

    "You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)

    HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.

  7. #502
    Join Date
    Jul 2005
    Location
    San Francisco
    Posts
    134

    Thumbs up

    Quote Originally Posted by PlainBill
    It depends on your definition of 'significant'.


    TCD140xxx TiVos cannot boot a killhdinitrd 3.1.5 kernel directly, the hacker must set up an in-line monte. They work fine with the killhdinitrd 7.2.2-oth.K1 kernel.

    PlainBill
    Has anyone with a TCD140060 verified that this kernel works? I don't want to have to pull my drives again. Also, I wonder if there is any advantage to it over Jamies custom 7.2.x kernel that I currently monte too from 3.1.1c.
    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)

  8. #503
    Join Date
    Jan 2002
    Posts
    5,601
    Quote Originally Posted by sucram65
    Has anyone with a TCD140060 verified that this kernel works? I don't want to have to pull my drives again. Also, I wonder if there is any advantage to it over Jamies custom 7.2.x kernel that I currently monte too from 3.1.1c.
    According to 7.1, the TCD140xxx has been verified to work properly with this kernel. As far as any advantages, it depends on what features you want. I believe Jamie compiles his kernels for better network performance; I'm not sure if he included the dhcp functionality.

    If you're happy with your present configuration, remember the rule - "If it ain't broke, don't fix it."

    PlainBill
    There's a difference between needing help, and just being plain ole' lazy.

    "You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)

    HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.

  9. #504
    Join Date
    Aug 2004
    Posts
    3
    Hi all.

    I'm about to killhdinitrd a TCD24004A Tivo on 7.2.2-oth.01-2-140. If I understand it correctly, killhdinitrd won't be able to modify my 7.2.2-oth.01-2-140 (yet), right?

    If this is the case, then I'll need to get 7.2.2-oth.K1 and killhdinitrd it, install it onto the Tivo, in order to get access at the Tivo's Linux OS.

    Once this is all done, each time a software update from Tivo comes down, it would require pulling the drive and reinstalling the killhdinitrd kernel again, since the update would overwrite the modified kernel and OS?

    Thanks for any help,
    Khoa

  10. #505
    Join Date
    Aug 2004
    Posts
    4,085
    Quote Originally Posted by KhoaTon
    I'm about to killhdinitrd a TCD24004A Tivo on 7.2.2-oth.01-2-140. If I understand it correctly, killhdinitrd won't be able to modify my 7.2.2-oth.01-2-140 (yet), right?
    Right.
    If this is the case, then I'll need to get 7.2.2-oth.K1 and killhdinitrd it, install it onto the Tivo, in order to get access at the Tivo's Linux OS.
    Right again.
    Once this is all done, each time a software update from Tivo comes down, it would require pulling the drive and reinstalling the killhdinitrd kernel again, since the update would overwrite the modified kernel and OS?
    Set "upgradesoftware=false" (most people do this in the boot page) to block upgrades. You can't do this forever (see this), but you can block it until you are ready to take the upgrade. If you have network and/or serial console access, it's possible to upgrade and rehack in place without needing to pull the drive.

  11. #506
    Join Date
    Aug 2004
    Posts
    3
    Thank you very much, Jamie.

    I successfully killhdinitrd my 7.2.2-oth.01-2-140 SA2 Tivo with your affirmations after making a few mistakes which required pulling the drive again (and again). I'm listing them so other beginners may avoid them:
    - Disable netfilter but not replace iptables => reboot loop (Thanks djsinc99 running into this problem and reporting)
    - Did not use "bootpage -p" to verify working boot partition => mods to wrong root partition
    - Did not use -C option in bootpage command to set parms => very early reboot loop

    Right in the middle of the modifications (took me more than a day in realtime due to other life tasks), my Tivo wanted to update to 7.2.2b-oth.01-2.140. I allowed it to do so. Upon reboot, I lost telnet to the Tivo as well as all mods. The software reload must have swapped root partition, installed new kernel and software. Had to pull the drive and redo everything.

    Jamie suggested that there's a way to upgrade and rehack without pulling the drive. Any hints as to how this can be done? Does it require serial console, since telnet will be wiped with the upgrade?

    Thanks,
    Khoa
    Last edited by KhoaTon; 05-09-2006 at 05:08 AM.

  12. #507
    Throg Guest
    Quote Originally Posted by KhoaTon
    Jamie suggested that there's a way to upgrade and rehack without pulling the drive. Any hints as to how this can be done? Does it require serial console, since telnet will be wiped with the upgrade?
    Scanman spelled it out for you here. All without pulling your drive.
    Cheers

  13. #508
    Join Date
    Jul 2005
    Location
    Naperville, IL
    Posts
    164
    Quote Originally Posted by Throg
    Scanman spelled it out for you here. All without pulling your drive.
    Cheers
    I assume if we're not using a monte system we need to wait for a suitably patched kernel? For now I've disabled the reboot command per Scanman's instructions, so at least the thing won't be rebooting every night.

  14. #509
    Join Date
    Aug 2004
    Posts
    4,085
    Quote Originally Posted by diamondsw
    I assume if we're not using a monte system we need to wait for a suitably patched kernel?
    You can use the same kernel you used before (3.1.5 or 7.2.2-oth-K1). Generally kernels don't change much within minor release cycles (7.1, 7.2, ...).
    For now I've disabled the reboot command per Scanman's instructions, so at least the thing won't be rebooting every night.
    Unless I'm confused, I don't think that's going to prevent 2am reboots. You need something like the "No Thanks!" patch for that, but there is no point in blocking this upgrade, as far as I can tell.

  15. #510
    Join Date
    Jul 2005
    Location
    Naperville, IL
    Posts
    164
    Quote Originally Posted by Jamie
    You can use the same kernel you used before (3.1.5 or 7.2.2-oth-K1). Generally kernels don't change much within minor release cycles (7.1, 7.2, ...).Unless I'm confused, I don't think that's going to prevent 2am reboots. You need something like the "No Thanks!" patch for that, but there is no point in blocking this upgrade, as far as I can tell.
    Ah, I understand now. In a nutshell, I thought that the upgrade was being attempted at 2am [blocked by my bootpage], and then it reboots into it. In reality, it's just rebooting at 2am, and on boot it should notice the upgrade and load it then [blocked by my bootpage] and reboot when done. So, the 2am reboot is a completely different reboot from the one I removed.

    Thanks for the kernel tip - once I'm done recording things this evening I'll upgrade (and we'll see if my "hda4=384MB but hda7=128MB" issue causes any problems).

    If things do go wrong, I assume I can pull the drive and set the bootpage back to /hda4, and I'll be no worse off than I started (other than it rebooting at 2am again).

Posting Permissions

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