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

Thread: 4.0.1b killhdinitrd rebooting problem

  1. #1
    Join Date
    Apr 2004
    Location
    SF Bay Area, California
    Posts
    53

    4.0.1b killhdinitrd rebooting problem

    DDB
    OK here's my plea for help - I've read and read on reboot issues but haven't come across an answer that seems correct and of course my bash cable isn't working (just ordered a new one). Maybe, maybe someone might have an idea as to what I can try until my trusty UPS man brings my new cable?

    Here's my configuration:
    HDVR2
    Samsung 160G drive (fdisked to blow away old tivo image)
    Subbed card
    Linksys USB200M
    PTV $5 Enhanced LBA48 boot CD w/S2_kernels
    and a Frustrated Blonde

    Here's what I did:
    1. fdisked /dev/hdc (my Samsung)
    2. I booted off my PTV Boot CD (from above)
    3. I restored a purchased/good 4.0.1b image extracted from a PTV Instacake (TCD240080) with mfsrestore - s 127 -xzpi to my samsung drive
    4. my boot partition (after mounting successfully /dev/hdc7) was 7
    copied my 4.0.1a vmxlinux S2_kernel from the PTV cd into both the 3 and 6 partitions (got the 1+1 from both) by using
    dd if=/tivo/var/vmlinux.px of=/dev/hdc3
    dd if=/tivo/var/vmlinux.px of=/dev/hdc6
    5. modified my bootpage with:
    /bootpage -P "root=/dev/hda7 dsscon=true console=2,115200 upgradesoftware=false" -C /dev/hdc
    6. and used the following rc.sysinit.author:
    Code:
    #!/bin/bash
    
    export TIVO_ROOT=
    export MFS_DEVICE=/dev/hda10
    
    tnlited 23 /bin/bash -login &
    tivoftpd
    fakecall.tcl
    
    route add -host 204.176.49.2 gw 127.0.0.1
    route add -net 204.176.49.0 gw 127.0.0.1 netmask 255.255.255.0
    7. made it executable - chmod 755 rc.sysinit.author

    8. Disabled the netfilter
    mv /tivo/etc/netfilter-enable /tivo/etc/netfilter-notenabled

    9. returned the drive to the tivo
    10. it boots and gets me far enough to the dish setup but after getting to where it detects the satellite settings (ying-yang ball on both satellites after doing signal strength) it reboots - once it did it and went to a GSOD.

    11. cried my eyes out - not really but definately pounded my desk

    Any ideas guys? sorry if I totally missed something (not sure about not having a path... I'll go try that....)

    TIA,
    -- Steph

    P.S. I used this 4.0.1b image on my DVR40 (with the same PTV boot disk/image disk and the 3.1.1c custom kernel) and it worked perfectly using Huge's guide - wondering now if something happened to my HDVR2 hardware.....
    Last edited by Stephanie; 02-18-2005 at 12:47 AM.

  2. #2
    Join Date
    Jan 2005
    Location
    New York
    Posts
    31
    Quote Originally Posted by Stephanie
    DDB
    OK here's my plea for help -
    [clip]
    10. it boots and gets me far enough to the dish setup but after getting to where it detects the satellite settings (ying-yang ball on both satellites after doing signal strength) it reboots - once it did it and went to a GSOD.

    11. cried my eyes out - not really but definately pounded my desk
    Did you let the GSOD finish? And if so, at what point in the process does is now reboot?

  3. #3
    Join Date
    Apr 2004
    Location
    SF Bay Area, California
    Posts
    53
    Yes waited out the GSOD to the end and it rebooted.
    It returned to the Guided Satellite Setup (pick the number of LNB's the dish has). Trying to continue the setup, when I got back to the screen right after the signal strength check that looks at the switch (the spinning white and black wheel - ying/yang) is where it locks up and then blanks and reboots (sorry can't remember the title of that screen, is where it hangs).
    Last edited by Stephanie; 02-18-2005 at 12:49 AM.

  4. #4
    Join Date
    Jan 2002
    Posts
    5,601
    Almost evrything you did looks reasonable. It isn't necessary to fdisk the drive to get rid of the old image - mfsrestore handles that for you. And make sure you restore with a non-lba boot disk unless you are going to monte into an LBA kernel.

    Handle the problem logically. In any failure list the possible causes and analyse how to eliminate as many as possible as easily as possible. In this case, possible causes are (in order of probability):

    a. Error adding the hacks
    b. Bad hard drive
    c. Bad image
    d. Hardware problem (other than hard drive).
    e. Random, non reproducible error.

    IF you have a 'spare' hard drive, the quickest test you can do is restore the image to it and stick it in the system without hacking it. If it works, you know the problem was either a. or b. Next restore the image to the 160 gig drive and test that. Again, if it works, you're down to a.

    The same technique can be used to isolate an error hacking the drive. Install a killhdinitrd kernel, test the drive. If it works, Load AlphaWolf's Series 2 utilities and set up a minimal rc.sysinit.author - paths and telnet only. When you get that working, you can add the rest of the hacks until everything is working.

    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.

  5. #5
    Join Date
    Apr 2003
    Posts
    588
    The only thing that stands out to me is:

    Did you restore the image using bzxpi (or did you use mfsadd to expand the drive to the full 160), and are perhaps NOT using an lba48 kernel?

    Bill: If you don't expand the drive, and don't use the lba48 kernel, does it matter if you restore from the lba48 disk or not? If yes, why?

    Thanks,
    Doc

    There's no place like ~

  6. #6
    Join Date
    Apr 2004
    Location
    SF Bay Area, California
    Posts
    53
    Doc - actually good point, I didn't use the b option (got to look at those mfsxxxxx parameters one of these days!
    Bill - looks like it's the hardware - just put back in the orig hdvr2 drive (factory Maxtor) and it hangs at the almost there.....
    Get this I called the 800 number that was the old Hughes service line and they direct you back to 800-DIRECTV. They then did some troubleshooting (ya know unplugging and plugging back in solves everything in their mind ) and said that they would have a tech out to my house tomorrow to troubleshoot and/or replace it with a new one! WOW! I'm impressed. This is a new level of customer support from them! Hopefully they'll give me a DVR40
    I'll keep you updated....

    Mods can you move as appropriate

    Thanks guys!
    -- Steph

  7. #7
    Join Date
    Apr 2003
    Posts
    588
    Quote Originally Posted by Stephanie
    Doc - actually good point, I didn't use the b option (got to look at those mfsxxxxx parameters one of these days!
    Bill - looks like it's the hardware - just put back in the orig hdvr2 drive (factory Maxtor) and it hangs at the almost there.....
    Get this I called the 800 number that was the old Hughes service line and they direct you back to 800-DIRECTV. They then did some troubleshooting (ya know unplugging and plugging back in solves everything in their mind ) and said that they would have a tech out to my house tomorrow to troubleshoot and/or replace it with a new one! WOW! I'm impressed. This is a new level of customer support from them! Hopefully they'll give me a DVR40
    I'll keep you updated....

    Mods can you move as appropriate

    Thanks guys!
    -- Steph
    Or you could end up with an R10... Watch out.

    If I remember right, the -b option is byteswapping. If you didn't use it, I would imagine it'd cause major problems (but I would think, so major that you wouldn't have gotten as far as you did).

    Doc

    There's no place like ~

  8. #8
    Join Date
    Apr 2004
    Location
    SF Bay Area, California
    Posts
    53
    Thanks Doc!

    I'm using the PTV upgrade ($5) LBA boot disk which I believe does a noswap by default. The hours ended up from 80 to 175 (on a 160Gig drive) and I think that sounds about right. FYI used their 4.0.1a kernal as well.

    Oh god - I hope that I don't end up with Garbage from the DirecTV folks - guess I just assumed that they would bring out a refurb (or hopefully new) DVR-40

    P.S. just created a drive for my other HDVR2 and it's working fine - PlainBill you were great with the suggestions related to troubleshooting!!

    Thanks DDB ROCKS!!
    --Steph
    Last edited by Stephanie; 02-18-2005 at 02:48 PM.

  9. #9
    Join Date
    Apr 2003
    Posts
    588
    I don't have this disk, but don't know if the kernel you're using is lba48... This could cause your problems I think.

    Doc

    There's no place like ~

  10. #10
    Join Date
    Nov 2001
    Location
    Southern California
    Posts
    938
    Quote Originally Posted by DocTauri
    Bill: If you don't expand the drive, and don't use the lba48 kernel, does it matter if you restore from the lba48 disk or not? If yes, why?
    I'm curious about this as well.....

  11. #11
    Join Date
    Apr 2003
    Posts
    2,402
    Check bootpage -b to make sure it is 6.
    Did you restore the DVR40's image to the drive? If so, is one a RID unit (DVR40) and one not (DVR2)? That could be the problem it is has the wrong dssapp on it.
    Check the boot messages from the $5 disk to see what drive size is reported. Or pdisk will tell you also if you're trying to use the whole disk when TiVo's kernel can only see 137GB.
    cat /etc/fstab
    cat /etc/mtab
    Look for anomalies (like hda4 being mounted instead of hda7).

    ew

  12. #12
    Join Date
    Jan 2002
    Posts
    5,601
    Quote Originally Posted by DocTauri
    The only thing that stands out to me is:

    Did you restore the image using bzxpi (or did you use mfsadd to expand the drive to the full 160), and are perhaps NOT using an lba48 kernel?

    Bill: If you don't expand the drive, and don't use the lba48 kernel, does it matter if you restore from the lba48 disk or not? If yes, why?

    Thanks,
    Doc
    No, it wouldn't. I've never heard of this problem occuring as an LBA-48 complication. LBA-48 failures occur when a drive 'wraps around' the 137 Gig limit and overwrites something - usually the partition table. The chances of this occuring while running guided setup are remote. If you never expand the image, the TiVo will never try to write past the 137 Gig barrier, and the problem can't occur.

    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.

  13. #13
    Join Date
    Jan 2002
    Posts
    5,601
    Quote Originally Posted by eastwind
    Check bootpage -b to make sure it is 6.
    Did you restore the DVR40's image to the drive? If so, is one a RID unit (DVR40) and one not (DVR2)? That could be the problem it is has the wrong dssapp on it.
    <SNIP>

    ew
    Wrong. The target system is an HDVR2 (non-RID). All RID software 3.x includes the drivers for non-RID systems. I have personally verified this.

    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.

  14. #14
    Join Date
    Apr 2003
    Posts
    2,402
    Quote Originally Posted by PlainBill
    Wrong. The target system is an HDVR2 (non-RID). All RID software 3.x includes the drivers for non-RID systems. I have personally verified this.

    PlainBill
    That's what I said....DVR2 = not-RID. I guess I thought she was using software version 4.0.1b.

    Quote Originally Posted by Stephanie
    P.S. I used this 4.0.1b image on my DVR40 (with the same PTV boot disk/image disk and the 3.1.1c custom kernel) and it worked perfectly using Huge's guide - wondering now if something happened to my HDVR2 hardware.....
    Is it possible to use the same image on a RID and non-RID unit? I thought for some reason there was a problem with dssapp...


    ew

  15. #15
    Join Date
    Jan 2002
    Posts
    1,778
    Quote Originally Posted by eastwind
    Is it possible to use the same image on a RID and non-RID unit? I thought for some reason there was a problem with dssapp...
    The stock 4.x dssapp will not work on a Uma6. (Anyone want to raise their hand and explain why?)

    Obviously, nothing keeps you from making a script that queries the BORD value or probes for uma6fix.o to decide which dssapp to use. The image would then work on Uma4, Uma6, and maybe even SA boards.

    Note that when uma6fix.o successfully loads, it changes the BORD value to that of a Uma4.

Posting Permissions

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