4.0.1b killhdinitrd rebooting problem

[Stephanie]

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:

#!/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.....

[WRabbit8]

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?

[Stephanie]

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).

[PlainBill]

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

[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

[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

[DocTauri]

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

[Stephanie]

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

[DocTauri]

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

[hayreass]

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.....

[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.
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

[PlainBill]

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

[PlainBill]

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

[eastwind]

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.

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

[alldeadhomiez]

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.