no update for HDVR2?

[rtype]

Ok, here's what I've got so far:

1. Hughes HDVR2 bought, registered, legally paying for, standard P4 card, Tivo subscription, etc.

2. I bougth 2 Maxtor 160G drives, flipped them to run in quiet mode and installed using the Twinbreeze kit with the quieter fans

3. Installed the U5 image - a tricky part of this was that in order to get it to work, I had to install the first drive, boot the Tivo, then do a Clear and Delete Everything, THEN do the mfs add for the second drive. If I added the second drive without doing the Clear and Delete Everything first, it hung at the Powering Up screen repeatedly. Cool now, showing 243 hours.

4. Got Bash via the Ingineer instructions using a home made serial cable

5. Left Tivo on overnight to do a successful call and get beamed the local channels -- still showing U5 as the software version

6. Installed Elvis (vi-like editor)

7. Created the fixsub31.tcl and callfixsub.tcl files

8. Installed the mips-compiled kmem

9. Ready to change my hackinit (would appreciate anyone letting me know if this is ok):
#!/bin/bash
echo "Starting Hackinit..." > /dev/ttyS2
PATH=/var/hack/bin:/sbin:/bin:/tivobin:/tvbin:.
TIVO_ROOT=
MFS_DEVICE=/dev/hda10
IGNOREEOF=1000
export PATH TIVO_ROOT MFS_DEVICE IGNOREEOF
echo "Sleeping 60 seconds for time sync/setup..." > /dev/ttyS2
sleep 60
date>>/var/hack/hackinit.log
/bin/bash</dev/ttyS2&>/dev/ttyS2&
echo "Calling FixSub..." > /dev/ttyS2
/var/hack/callfixsub.tcl &
echo "Setting mem to no scramble..." > dev/ttyS2
/var/hack/bin/kmem 800b23b4 00001021

9. Ok, this is where I'm at -- I desperately need to know explicitly how to prevent software updates. I've done lots of searching here but found some conflicting answers. Can anyone specifically who has an HDVR2 tell me how to make sure I don't get any updates via the beam?

Thanks a lot for all your help. I'm getting there.

[chazman]

without re-typing the procedures and possibly adding to the conflicting information... The method of modifying the sysinit.rc file by commenting out the upgrade lines in the script has been successful for me for over a month. I have not been using the upgradesoftware=false method and I still have not been upgraded. I thing that the upgrade has been downloaded but never installed. That is how it is supposed to work.

Chaz

[rtype]

Originally posted by chazman
without re-typing the procedures and possibly adding to the conflicting information... The method of modifying the sysinit.rc file by commenting out the upgrade lines in the script has been successful for me for over a month. I have not been using the upgradesoftware=false method and I still have not been upgraded. I thing that the upgrade has been downloaded but never installed. That is how it is supposed to work.

Chaz
chazman

Thanks. I'd read that method but was unable to locate the sysinit.rc file. I thought maybe that was only for Series 1. Can you tell me which dir this is located in?

[Dr. Phil]

Originally posted by rtype
chazman

Thanks. I'd read that method but was unable to locate the sysinit.rc file. I thought maybe that was only for Series 1. Can you tell me which dir this is located in?

Try rc.sysinit instead.

[rtype]

Originally posted by Dr. Phil
Try rc.sysinit instead.
I didn't see that one either. Again, which directory?

[chazman]

see.. there I go again introducing confusion.

Chaz

[rtype]

Does renaming/moving the install scripts work reliably? If so, I'd rather do that method anyway so that I still get Tivolution and whatnot.

It seems like they could just beam you new install scripts, though.

[Dr. Phil]

Originally posted by rtype
Does renaming/moving the install scripts work reliably? If so, I'd rather do that method anyway so that I still get Tivolution and whatnot.

It seems like they could just beam you new install scripts, though.

You can clearly see where the new software is unpacked and installed in rc.sysinit and the scripts that it invokes. Follow the program logic and you will be able to tell what a particular change will do.

What's this about Tivolution?

[devnull]

I'm having trouble with my elvis install and thought I'd ask for some help.

There isn't a README in the S2 elvis package, so I'm kinda guessing here. I've done the following:

1. Put libtermcap.so.2.0.8 that came with Elvis into /lib
2. Taken the small termifo database packaged with the Series 1
version of Elvis, put that in /var/hack and set TERMINFO to it's
location.

Elvis continues to behave very non-curses like. The cursor line is correctly printed, but as only a single line at the bottom of the screen.

Any ideas?

gary

[mrblack51]

Originally posted by rtype
2. I bougth 2 Maxtor 160G drives, flipped them to run in quiet mode and installed using the Twinbreeze kit with the quieter fans


well, you are going to have bigger problems than updates once your tivo gets full. the tivo can only use 137gb drives or smaller. it will claim that it sees all the space, but it will screw up when it tries to use it.

[devnull]

Okay, thanks to some prompting from TheWickedPriest I now have elvis working.

All I did was (drum roll for the stupid here) set TERM=xterm (the only natively supported terminal on the Tivo) and everything worked.

I've since backed out my TERMINFO setting, libtermcap, and the terminfo database and everything still works.

So all that was really needed was:
1. Unpack elvis, put it in the path
2. TERM=xterm

gary

[CaptainStupid]

Originally posted by mrblack51
well, you are going to have bigger problems than updates once your tivo gets full. the tivo can only use 137gb drives or smaller. it will claim that it sees all the space, but it will screw up when it tries to use it.

Any way to keep the TiVo from thinking it has more than 137? Everything I've read up to this point seems to indicate that the TiVo will only recognize the 160's as 137. I'm confrused.

[rtype]

Originally posted by CaptainStupid
Any way to keep the TiVo from thinking it has more than 137? Everything I've read up to this point seems to indicate that the TiVo will only recognize the 160's as 137. I'm confrused.
As far as I am aware, this is the case. There should be no issue with using the 160g drives (other than that you pay for more than you get). My HDVR2 seems to be seeing all 243 hours just fine.

[mrblack51]

Originally posted by rtype
As far as I am aware, this is the case. There should be no issue with using the 160g drives (other than that you pay for more than you get). My HDVR2 seems to be seeing all 243 hours just fine.

nope, thats not the case. the tivo will see the 160gb as 160, since thats what mfstools will report. however, as i said before, once it tries to use the space, all hell will break loose.

[rtype]

Originally posted by mrblack51
nope, thats not the case. the tivo will see the 160gb as 160, since thats what mfstools will report. however, as i said before, once it tries to use the space, all hell will break loose.
Believe what you want but I'm sitting here with 243 hours of Tivo on my HDVR2 with two 160gig drives and it's working fine.

Weaknees sells them with this configuration, also.

[fixn278]

Originally posted by rtype
Believe what you want but I'm sitting here with 243 hours of Tivo on my HDVR2 with two 160gig drives and it's working fine.

Weaknees sells them with this configuration, also.

Is it possible the machine you did the restore/expand on only saw 137gb so that's what it wrote when doing the expansion?

[CaptainStupid]

Originally posted by mrblack51
nope, thats not the case. the tivo will see the 160gb as 160, since thats what mfstools will report. however, as i said before, once it tries to use the space, all hell will break loose.

Can you please tell me how to prevent this?

[DblDamage]

Originally posted by mrblack51
nope, thats not the case. the tivo will see the 160gb as 160, since thats what mfstools will report. however, as i said before, once it tries to use the space, all hell will break loose.

Mr. Black, could you elaborate on this? From what I've read you would only have problems if you ran MFSTools from a system operating Redhat 8.0 (or equivalent that supports LBA-48).

I do not have a 160GB drive installed, but I do have room for one. I would like to know before I upgrade.

Thanks,

DblDamage

[tivomaster]

Originally posted by CaptainStupid
Can you please tell me how to prevent this?

I can attest to the problem that Mblack51 describes. I had a Maxtor 160 that would work like a champ until it started getting full then it would start the click of death. I tried this 2 times before I started remembering back to the dos 2gb/bios problems. When we would attempt to put a 4gb drive in a bios limited machine it would experience almost the exact same symptom. What I did to hopefully prevent it was download a tool from Hitachi (http://www.hgst.com/hdd/support/download.htm) . This tool allowed me to force my Maxtor 160 to think it was a 135gb (I chose 135 to be on the safe side). It seemed to work and MFStools reports the "fake" size. I can't be sure yet because I haven't got the drive full yet.

[DblDamage]

tivomaster:

Maxtor has a utility in their Maxblast 3 software that will apparently do the same thing as the Hitachi Feature Tool you're using.

Just an FYI for all you Maxtor users out there.


DblDamage

[mrblack51]

Originally posted by DblDamage
Mr. Black, could you elaborate on this? From what I've read you would only have problems if you ran MFSTools from a system operating Redhat 8.0 (or equivalent that supports LBA-48).

I do not have a 160GB drive installed, but I do have room for one. I would like to know before I upgrade.

Thanks,

DblDamage

rtype: i understand it works fine now. record enough tv so that it fills up, then tell me if it is still running fine when you are close to full. it will work fine until you start trying to use the space above 137gb, then it will freak. if you got dual drives from weeknees, they may have set you up with a hacked kernel, but i kinda doubt it.

the lba48 issue is that lba48 is not enabled in the tivo kernel. on the pc, you can use mfstools to setup the drive and it will report full time. however, it will freak out when you hit the space that it can't find. there is lots of discussion of this here and over at AVS.

bottom line, if there was no need for an LBA48 patch, people wouldnt do it.

[DblDamage]

Originally posted by mrblack51
the lba48 issue is that lba48 is not enabled in the tivo kernel. on the pc, you can use mfstools to setup the drive and it will report full time. however, it will freak out when you hit the space that it can't find. there is lots of discussion of this here and over at AVS.

bottom line, if there was no need for an LBA48 patch, people wouldnt do it.

But aren't those people trying to use the full capacity of their drives?

I understand the Tivo's 137GB limitation. But are you saying that the bootable MFS Tools2 CD will recognize the full 160GB of the drive and partition it as such?

If that is the case, then I can see where problems could occur.


DblDamage

[rtype]

Once again, my HDVR2 is completely full with 243 hours of content and working fine. I have many movies recorded with keep until space is needed and this week they began to be deleted for new scheduled recordings, just as expected.

The kernel patch is to address greater than 137 gigs. This would allow you to use all 160 gigs on my drives and get closer to 280 hours or so. It would also allow you to use 250 gig drives.

[crazyrat]

Please pardon my interruption, but what kernel patch?

[rtype]

Originally posted by crazyrat
Please pardon my interruption, but what kernel patch?
This one: ftp://ftp.courtesan.com/pub/millert/TiVo/kernel/

[roach]

Originally posted by mrblack51
rtype: i understand it works fine now. record enough tv so that it fills up, then tell me if it is still running fine when you are close to full. it will work fine until you start trying to use the space above 137gb, then it will freak. if you got dual drives from weeknees, they may have set you up with a hacked kernel, but i kinda doubt it.

the lba48 issue is that lba48 is not enabled in the tivo kernel. on the pc, you can use mfstools to setup the drive and it will report full time. however, it will freak out when you hit the space that it can't find. there is lots of discussion of this here and over at AVS.

bottom line, if there was no need for an LBA48 patch, people wouldnt do it.

Just to confirm this... I installed 2 160GB Western Digital drives before finding this thread. I have intermittent problems with some shows suddenly becoming unavailable as well as shows that have bad "spots" in them. Blech, time for a LBA48 patch I guess.

[DblDamage]

Originally posted by roach
Just to confirm this... I installed 2 160GB Western Digital drives before finding this thread. I have intermittent problems with some shows suddenly becoming unavailable as well as shows that have bad "spots" in them. Blech, time for a LBA48 patch I guess.

What did you use to expand to your new drives? A boot CD, or MFSTools 2 disc with an operating system that supports lba48?

Did you pull the drives and run a utility to scan for bad blocks?

Need info. I plan on upgrading this weekend.


DblDamage

[mrblack51]

Originally posted by DblDamage
What did you use to expand to your new drives? A boot CD, or MFSTools 2 disc with an operating system that supports lba48?

the mfstools 2 disk and all boot cds contain their own operating system. the mfstools 2 disk should support lba48, but thats not the problem. the problem is on the tivo, and the tivo kernel's lack of support for lba 48

[DblDamage]

Mr. Black, I am getting conflicting information. Here is a recent post from the AVS Forums:

Originally posted by Robert S
If you boot the MFS Tools 2.0 boot CD, then your PC will have the same 137Gb limit as the TiVo.

If the boot CD recognizes 160GB and larger drives as 137GB, and the Tivo kernel recognizes 137GB, where is the source of corruption coming from?

I'm not trying to be argumentative, I'm just trying to find the right answers.

Thanks,

DblDamage

[mrblack51]

Originally posted by DblDamage
Mr. Black, I am getting conflicting information. Here is a recent post from the AVS Forums:

If the boot CD recognizes 160GB and larger drives as 137GB, and the Tivo kernel recognizes 137GB, where is the source of corruption coming from?

I'm not trying to be argumentative, I'm just trying to find the right answers.

my understanding is this:

if you boot on a setup that recognizes 160gb as 137gb, and thats all that the space that mfstools shows, then you should be fine.

however, if you boot in a setup that recognizes the full 160gb, then you will have problems.

[DblDamage]

Mr Black:

Thank you for your reply. Now we are on the same page.

It would be interesting to set up a poll and find out how many of us have had problems with upgrades using drives 160GB and larger.

Roach,

I would like to know what your initial setup was, and if you scanned the drives for bad blocks.

Keep the faith,

DblDamage

[roach]

Originally posted by DblDamage
What did you use to expand to your new drives? A boot CD, or MFSTools 2 disc with an operating system that supports lba48?

Did you pull the drives and run a utility to scan for bad blocks?

Need info. I plan on upgrading this weekend.


DblDamage

I used an old RedHat version (no LBA support) and that couldn't even get me off the ground. I recompiled the latest linux kernel (along with the Tivo partition magic patches) for my RedHat machine and that worked to get me going except I ran into the aforementioned issue(s). Last night I zapped the whole config and used the Hitachi util that was mentioned earlier in the thread. This seems to have worked perfectly. I haven't filled the thing up yet, but it should be well on it's way by Friday so I'll drop another post to let you know. Just to re-iterate I'm using Western Digital HDs with that Hitachi util and it worked great, I was even able to activate the AAM feature and set a custom value which has made some noticeable difference in the noise that the drives make.

[walaroo]

So the kernal patch runs on the HDVR2, right?

I looked at the various files available and
noted that the utilities there are compiled for
the PPC. No mention is made for which processor
the kernals are built for.

Can some one clarify this for me, please?

Also, which kernal would I want to use with U5 3.1,
if they are compiled for MIPS.

TIA,
W

[mrblack51]

Originally posted by walaroo
So the kernal patch runs on the HDVR2, right?

I looked at the various files available and
noted that the utilities there are compiled for
the PPC. No mention is made for which processor
the kernals are built for.

Can some one clarify this for me, please?

Also, which kernal would I want to use with U5 3.1,
if they are compiled for MIPS.

TIA,
W

the patch that was pointed to was for the series 1 units. while the patch can be applied to series 2 units, nobody has done it and released it yet.

[roach]

Originally posted by walaroo
So the kernal patch runs on the HDVR2, right?

I looked at the various files available and
noted that the utilities there are compiled for
the PPC. No mention is made for which processor
the kernals are built for.

Can some one clarify this for me, please?

Also, which kernal would I want to use with U5 3.1,
if they are compiled for MIPS.

TIA,
W

I recompiled the kernel on my PC not for the TiVo. The patch I used enabled the PC to read the partition map from the TiVo drives. I used the again mentioned Hitachi util to shrink the "capacity" of my drives instead of trying a patched kernel for my TiVo.

[walaroo]

Thanks for the clarification.

I know the Series 2 DTivo is not a popular unit yet,
but heck this *IS* a Series 2 disscussion area.

So if something is mentioned that is NOT Series 2,
that should be made clear.

I suppose now I will have to figure out how to
do cross compiles for the MIPS too.

I am beginniing to "feel the joy!"

Thanks......W

[roach]

Originally posted by DblDamage
Roach,

I would like to know what your initial setup was, and if you scanned the drives for bad blocks.

Keep the faith,

DblDamage

Sorry about taking so long to wite this all out, but I wanted to include all the info I could,

Initial setup:

I used 2 160GB hard drives on a Redhat 7.1 machine running a 2.4.21 kernel that had been compiled with the tivo magic patches so the partition tables could be seen. The drives showed up as 160GB and mfstools reported 300 some hours of recording time. This setup cause errors where the TiVo would claim that the recording was blank as well as some recordings would have 5-6 minute parts that could not be viewed after only 20%-30% of the total capacity of the drives had been used.

After reading Mr. Blacks comments I used the Hitachi tool to turn the capacity of the drives down to 137GB each. Ran mfstools again which gave me a total of 260 (or so) hours. So far I've filled up 38% of the total capacity of the drives with NO errors.

DblDamage, I hope this helps you at all and I appologize for not getting back before the weekend.

[DblDamage]

Originally posted by roach
DblDamage, I hope this helps you at all and I appologize for not getting back before the weekend.


No problem. This pretty much confirms what mrblack and I posted above.

I drop-kicked a new 160GB drive in my HDVR2 on friday. The MFSTools2 boot CD I used saw the drive as 137GB so I figure I'm safe. I will repost if anything goofy happens once the drive fills up.


DblDamage

[DjPK]

I have the sas2 but thought i should keep this in this thread.

Here is what I am going to comment out of rc.sysinit.
Will this prevent software updates?
Do I need to comment out all of this?

Thanks in Advance,
Paul Kraus

rc.sysinit
-----------
if [ -f /sbin/update ] ; then
# ??? Does this really add value?
echo "Starting update ..."
/sbin/update
fi

echo "Check for PROM update ..."
if [ "$updateprom" = true ]; then
if [ -e /prom/TiVoProm.bin ]; then
osdwriter /tvbin/InstallingSoftware.$TV_STD.png
getprom -Update /prom/TiVoProm.bin
echo "Sleep...waiting for reboot"
osdwriter /tvbin/PromScreen2Version7.$TV_STD.png
sleep 1000000
restart
fi
echo "Can't find PROM image"
fi



# Check for software upgrade
if [ "$swupgrade" = true ]; then
/tvlib/tcl/updateSoftware.tcl
fi

[Ozy666]

Originally posted by DjPK
I have the sas2 but thought i should keep this in this thread.

Here is what I am going to comment out of rc.sysinit.
Will this prevent software updates?
Do I need to comment out all of this?

Thanks in Advance,
Paul Kraus


stuff deleted



Apparantly the rc.sysinit is processed well before it is replaced by the hackinit script...therefore, any modifications you are making to the rc.sysinit are useless.

I moved the updateSoftware.tcl (and SWInstall.itcl) files out of the tvlib directory, and it seems to work fine. However, I don't know for sure if this will prevent updates or not.

Note, the filenames and directory are from memory, so may be slightly different.

Ozy

[DjPK]

I thought a monted tivo rc.sysinit would not be over written. Is this incorrect?

[ronnythunder]

correct. but i think the other posters weren't talking about using monte; they were using the u5 kernel with 3.1.0 userland. with monte, there's a u5 kernel and u5 root filesystem that get loaded and checked, then the 3.1.0 kernel is loaded (without the checking) and it works with the 3.1.0 root filesystem which remains untouched.

monte is definitely the way to go imho.

ronny

[DjPK]

So using monte would the above work in preventing the software updates. I think i will but i think i got over zeolous and don't need to comment out all of that.

[Ozy666]

Originally posted by ronnythunder
correct. but i think the other posters weren't talking about using monte; they were using the u5 kernel with 3.1.0 userland. with monte, there's a u5 kernel and u5 root filesystem that get loaded and checked, then the 3.1.0 kernel is loaded (without the checking) and it works with the 3.1.0 root filesystem which remains untouched.

monte is definitely the way to go imho.

ronny

Yeah, I currently don't have a monte'd system...I'll probably give that a try once I feel confident enough. Maybe I'll wait until the rumored update comes down the pipe.

Until then, moving/renaming the update scripts _should_ work for either methods of hacking, though I agree that modding the rc.sysinit for the monte'd system seems a much cleaner method.

Ozy

[dogbreath]

rtype

How about a how-to for elvis.

dogbreath