noob getting ready to do a HDVR2 to 4.01b upgrade some basic questions...

[Jeff D]

The background...
I've been doing a lot of reading about making a HDVR2 able to run 4.x and I really want to do this. The problem is that I'm basically a linux noob too, I can find my way around the drive and have some unix commands, but that's it. I've looked at haderak's "Hacking your HDVR2 with a 4.0.1b image and Tivoscripts 1.02 ISO " and AlphaWolf's slice upgrade process. I want to keep my current recordings (if possible) so I think AW's slice upgrade is the way to go.

I've got alphawolf's files for the 4.01b slice upgrade and reading through the threads on upgrades several things come up that I have no idea what they are and without that information I don't know how to figure out what I'll need to do.

Let me get the basics out there...
What's RID stand for? I see it mentioned all over, yet I don't know if my devices are RID or not.
EDIT: Google was good at to figure this out.. Receiver ID, ok, but now the threads I saw regarding this say it's a 12 digit number starting 000000. My box has a 15 digit DirecTV Service Number and it starts 151-0000-....-.... is this a RID?

Alphawolf talks about "chainload your kernel", any description somewhere of what chainloading is? Is monte method an example of chainloading?

Alphawolf also talks about returning a sleeper's ISO back to normal. From what I recall sleeper used one partition differently that it normally is, right?
I searched and couldn't find anything, not sure what good search words would be...

[hayreass]

RID stands for Receiver IDentification, and no, an HDVR2 is not an RID receiver.

You don't give a lot of info, like whether your unit is already hacked, how big your drive is, do you have bash access, etc.. so let's say this, to get 4.x to work on a HDVR2 with a small drive (<136gb), you don't need to chainload a kernel (with some exceptions)

As far as unsleepering a drive, search for "unsleeper" PlainBill made an excellent guide for doing that (if in fact you have a sleeper'd system)

Good Luck!

[Jeff D]

Yes, the unit is sleepered over a year ago, there was another box that I only suspect was sleepered too. I'll look for Bill's post, thanks for the keyword.

Unit was upgraded to 80hrs with using sleeper's iso and then some other patches have been applied like PPV and tytools updates. (pretty much those changes are all of the basic tivo hacks...)

BTW, I edited my original post after finding info (from you) on google about the RID. 15 digits and not 12 starting 151, I assume it's a new format for the same thing or the 151 is generic and ignored with only the lower 12 digits mattering. Looks like this wasn't the case and HDVR2 ins't RID, thanks!

[Jeff D]

Hayreass, Thanks for the info. And I do have BASH on the box.

Was this the thread you were talking about regarding plainbill?
http://www.dealdatabase.com/forum/showthread.php?t=38967

It's tough to find the threads that are relavent as there are often other things grouped within the same thread. For example LBA48, I'm using a 80GB so that's not an issue to me. There's also the IRD stuff which also doesn't apply.

From what I see I need
killhdinitrd to do this, but from what I read this only has to do with undoing the creating a RAM disk to pass the PROM check on a monte'd box.

I'm really confused as to what is important to be focusing on. There are a ton of tools and thing that may not be important to this case and I'd like to avoid using the few spare brain cells I have on stuff that wouldn't be helpful.

I'm the worlds best wild goose chaser, this really dosen't help with spagetti threads. =(



From what I've seen I need to:
unmonte the drive
get the slice files to the Tivo using dbload
run the installSw.tcl
mount new root and copy the files from the old root to the new one
(e.g. /tivo-bin, /tivoweb-tcl, /hack, /etc/rc.d/rc.sysinit.author, etc.)
However I have no idea what etc would be... just other stuff like tytools and any other customized things?
After all this I can reboot and it should work....

think I can skip all other stuff in alphawolf's steps as I'm not a UMA6 or LBA48 setup.

[hayreass]

Actually, I was referring to this one. (http://www.dealdatabase.com/forum/showpost.php?p=196162&postcount=3)
Just make sure you use a kernel appropriate for your software version.

Sounds like you have a pretty good handle on the rest of it, just make sure you edit /tvbin/installSw.itcl like he recommends (I've never done this, but I seem to remember reading you need to replace reboot with exit 0, do a search)

Also, I don't remember what a sleeper'd rc.sysinit.author looks like, but I bet you'll need to edit it a bit on the new root to match your config.

[Jeff D]

When I killhdinitrd an image do I need to use the same version as what I have on the box? My boxes both have 3.1.1b, the closest match for the kernels to patch with is 3.1.1c.

[The Only Druid]

When I killhdinitrd an image do I need to use the same version as what I have on the box? My boxes both have 3.1.1b, the closest match for the kernels to patch with is 3.1.1c.
I don't think you can use a kernel w/ an OS from before that kernel.

Update your b to e, then apply the c kernel.

[Jeff D]

Thanks, I'll look into that. While I'm looking i'm hoping someone will chime in that there's no need. =)

I was hoping this wasn't going to get too complicated and going from b to e and back to c might be a bit much.... but I'm willing to try.


Ok, started looking around and discovered a 3.1.1c slices group from alphawolf on emule. I had started to do that download before but it never finished. However I don't think I can use that as I can't unmonte my box without being at 3.1.1c.... right?

[RavenStL]

I used 4.0.1a kernel with the 4.01b software. It is Killhdinitrd compatible. On an HDVR2, actually 3. I guess you are going through the ropes for saving recordings though................ Otherwise, start fresh! (cue up the Mento's theme)

[Jeff D]

I used 4.0.1a kernel with the 4.01b software. It is Killhdinitrd compatible. On an HDVR2, actually 3.

That's what I was thinking... it's a minor upgrade so I don't suspect there should be problems. It's just that if it doesn't work I think I've screwed the drive over, and suspect it won't boot then. If this is true I'd be unhappy with no way to restore the "good" 3.1.1b kernel version.

[RavenStL]

ugh, I edited. and heres a post. lol

as the Wise man said,,, backup, backup, BACKUP!!!!!! :)

Once you get the images on your Fat32 drive, assuming you do it right, you can wipe and redo everything a ton of times and still go right back to where you were when you started.

[Jeff D]

while on the subject of backing up... I'll play with a clone of this drive, can someone tell me if this is the right command to us assuming that drive c (hda) is the source and d (hdb) is the copy.

dd bs=512 conv=sync if=/dev/hda of=/dev/hdb

Is that correct? Both drives are 80GB drives and I just hope they have the same number of sectors!

Ok they don't have the same number of sectors the destination is far smaller and there the 2048 vs 2000KiB which i don't understand. The number of sectors and total size is different so I don't know what to do...

any suggestions?

[PlainBill]

Jeff, AFIK, you can use a killhdinitrd 3.1.1c kernel with any version of TiVo software based on the 2.4.4 kernel. Check for posts by AlphaWolf on this to reassure yourself.

On the backup: Turn the problem around: Make an image of the working drive with mfsbackup; restore it to the 'test' (smaller) 80 Gig drive. Try the 3.1.1c killhdinitrd kernel on the test drive. If necessary, adjust the parameters you use for mfsbackup to get an image that will work on the test drive.

PlainBill

[bigtedshred]

And to confirm, you can use the 3.1.1c kernel on 3.1.1b software.. I just did it and have no problems.

[Jeff D]

Thanks guys!

I'm making one more post in the other thread (hate parallel topics) but these two now seem to be merging after just one or two posts. =(

[The Only Druid]

And to confirm, you can use the 3.1.1c kernel on 3.1.1b software.. I just did it and have no problems.

Count me corrected then.

[Jeff D]

I'm stuck with the mfsbackup -> mfsrestore...

I'm doing the dual backup/restore process with

mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdb

and it fails because the source is larger than the dest (hmmm) and I'm not sure how to handle this. Any ideas? I do want to backup the whole drive, right?

the other option I've seen is the dd copy (as I used before with the "noerror" addition. This looks like it just drops the extra data.
Using the following command:
dd conv=noerror,sync if=/dev/hda of=/dev/hdb bs=512
The same command minus the noerror was what I tried first that complained about the different sizes.

[psxboy]

You should be able to go straight to 4.0.1b using slices to upgrade. No need to go to 3.1.1c as an interim first:

1. Get 4.0.1b slices and a 4.0.1a killhdinitrd'ed kernel & copy them to your Tivo.
2. Modify your bootpage to remove the BASH_ENV stuff at the end.
3. Flip your bootpage.
4. dbload the 4.0.1b slices
5. Edit installSw.itcl to change the "reboot" line to "exit 0" & run it.
6. When it's done, dd your killhdinitrd'ed 4.0.1a kernel over top of the newly created 4.0.1b kernel.
7. Mount your new root & copy everything you want to keep over to it (rc.sysinit - if you've made changes, rc.sysinit.author, bin utilities, etc.).
8. Edit your rc.sysinit or rc.sysinit.author to remove lines that load network drivers (4.x loads these for you), remove lines that set network parameters like IP address, etc. (also done by 4.x) and anything else that shouldn't be there.
9. Rename netfilter_enable to netfilter_notenable (or anything else you want to rename it to) so it doesn't run.
10. Double check that your bootpage settings are correct (pointing to the correct root, and the active partition is the correct one)
11. Cross your fingers & reboot.

There are some subtleties in the above instructions that deserve more explanation. The "flip the bootpage" part is required so that the installSw.itcl file doesn't drop the new software into the wrong partitions. This was a side-effect of the "Sleeper" configuration. The "copy everything to the new root" part will depend on your system. You'll have to decide what you want to move over or not. And editing rc.sysinit(.author) to account for differences between 3.x and 4.x will probably require some research. You'll probably also need to read up on dbloading slices, dd'ing kernels, etc. Other than that, the above steps should work. Anyone else see any problems with it?

-psxboy

[PlainBill]

I'm stuck with the mfsbackup -> mfsrestore...

I'm doing the dual backup/restore process with

mfsbackup -Tao - /dev/hda | mfsrestore -s 127 -xzpi - /dev/hdb

and it fails because the source is larger than the dest (hmmm) and I'm not sure how to handle this. Any ideas? I do want to backup the whole drive, right?

the other option I've seen is the dd copy (as I used before with the "noerror" addition. This looks like it just drops the extra data.
Using the following command:
dd conv=noerror,sync if=/dev/hda of=/dev/hdb bs=512
The same command minus the noerror was what I tried first that complained about the different sizes.

Jeff, you can't use this command if the source drive is larger than the destination drive. Also, since your drive is Monte'd, you can't use mfsbackup at all. (I gave you bad information in another thread). Either borrow a larger drive and use the dd command; download an image and practice with that; or grit your teeth and do at least the 'TiVoscripts to killhdinitrd conversion. (http://dealdatabase.com/forum/showpost.php?p=196162&postcount=3)

Locate Hinsdale's How-to. It is full of information on copying drives. Because of the tools available for manipulating mfs partitions, you will have to use the -f or -l switch AND the -s switch if you hope to get an image that will restore to a smaller drive. You can't shrink a partition, the -s switch will eliminate it if it does not contain anything to back up.

PlainBill

[PlainBill]

PSXboy, your procedure should work. I'd be reluctant to try it without a test run if I had recordings I didn't want to lose, I imagine Jeff is even more reluctant.

PlainBill

[Jeff D]

PSXboy, your procedure should work. I'd be reluctant to try it without a test run if I had recordings I didn't want to lose, I imagine Jeff is even more reluctant.

PlainBill

Yes and no. I've just realized the dtivo is running really slow for everything. For example the main menu with the text wiping in from the right takes almost a minute to get to the final spot. The directlogo goes to a strage "blurred" version every few seconds. I'm thinking the drive might be on the way out. I'm thinking it might be time to just wipe the drive and scan the surface for bad sectors and go from there. I've never gone to a larger drive as I offload everything to DVD that I want to keep around.

PSXboy's idea about installing a virgin image and overwriting the kernel with a killhdinitrd version of the same kernel. I suggested that a few posts back and bill suggested not doing that... ?

The one thing that got me from all I read about the process moving up to 4.0 was to be sure you sleeper'd disk was unsleepered before doing anything else. That was my reason for doing the work to get to 3.1.1c as that was the only version of the kernel that was close to the installed 3.1.1b. And for some reason that I don't know it has been suggested to go from b to e and back to c. I don't know why you can't just go from b to c and be done...

[PlainBill]

If you want to move from 3.1.1b to 4.0.1b, all you have to do to unmonte is flip the boot page and change the boot paramters.

The bad news is - I agree with your diagnosis - it sounds like your hard drive is failing - which opens a whole 'nother' can of worms. SERIOUSLY consider buying a larger hard drive, installing a 4.0.1b image on that and hacking it; then transfering the recordings from the old drive to your pc with mfs-ftp; then from the pc to the new drive. Yes, this will be a pain, but it's the only way you're going to get use of all the space on the new drive.

PlainBill

[RavenStL]

And for some reason that I don't know it has been suggested to go from b to e and back to c. I don't know why you can't just go from b to c and be done...


I think th idea was for your unit to upgrade the SOFTWARE to E, which is DTV's most current software (i think). That also comes with a 3.1.1e Kernal (I think), so now you have to downgrade ONLY your kernal to 3.1.1c to get killhdinitrd to work.

So your unit will say it is 3.1.1e while its booting a 3.1.1c kernel. Now you can add 4.0.1b with that kernal. But your unit is sleepered and luckily I have NO idea how it works and dont want to know :) :)

[Jeff D]

So I did something different last night and it has triggered a few new questions.

I took a 4.01c image and installed that on the spare drive to see if it would work. After the mfsrestore I copied over a killhdinitrd moded vmlinux.px to hda3 and hda6 with the following commands:
dd if=/dev/zero of=/dev/hda3
dd if=vmlinux.px of=/dev/hda3
and the same for hda6

booted the box and it does seem to work with some minor issues.
1) the box shows error #51 and something about incompatible hardware. From what I've read before I think that resetting the box with the delete everything would fix that, but I want to apply some hacks before doing that.

2) the box says I need to "call home" and I'm not to sure about how smart this is to do with a version that's not suppose to be installed.

Should I start over with a 3.1.1c or e image with killhdinitrd and then make the call followed by using alphawolf's 4.0 upgrade via slices?

Now, this was just a testing/learning experience to see if I could get something 4.0 running. In that I think I got pretty far, but I still need to perfect the other process for another box.

[pdt]

1) the box shows error #51 and something about incompatible hardware. From what I've read before I think that resetting the box with the delete everything would fix that, but I want to apply some hacks before doing that.
Why do you want to install hacks if the tivo isnt working properly - how will you know if you messed something up? - Clear & Delete first

2) the box says I need to "call home" and I'm not to sure about how smart this is to do with a version that's not suppose to be installed.
It's not smart to call home with 4.01 software - This is what fakecall is for.

[hayreass]

Why do you want to install hacks if the tivo isnt working properly - how will you know if you messed something up? - Clear & Delete first

It's not smart to call home with 4.01 software - This is what fakecall is for.
For that matter, you could run 51killer.tcl to fix the error 51 message, and FakeCall40.tcl (http://www.dealdatabase.com/forum/showpost.php?p=197787&postcount=4) Should kill that call home nag every time you run it.

[Jeff D]

Ok,I'm still learning.

Thanks guys. I've got a lot of reading to do now on hacks. I saw sleeper's list of patchs and I'll do those.

I'll also do the nocalls script and have that run.

I need to enable telnet access first, so I'm off to do that and some other minor stuff.


Thanks again to everyone for the helpful info some of which I know has been covered many places before. I'm sure I'll have some other ?s. =?

[PlainBill]

So I did something different last night and it has triggered a few new questions.

I took a 4.01c image and installed that on the spare drive to see if it would work. <SNIP>

It could be a little hard finding hacks for that version. :)

PlainBill

[Jeff D]

b or c, yah... doh!

ANY TRICK TO GETTING BASH PROMPT ON 4.0?

I thought I put a good rc.sysinit.author on partition 7 with the edits for telnet support. But I also removed all my net configuration styuff from 3.0 vers as I'm told this is all automatic on 4.0, but nothing. the mac on my ethernet adapter is tied down to a specific IP an nothing works there.

I can't get a serial connection going either. 11520 (or whatever that speed is) 8m1 no handshake. And nothing.

I thought things were going pretty well, but this is unexpected...

[hayreass]

# Start BASH
/bin/bash </dev/ttyS2&>/dev/ttyS2&

# Load telnet daemon
tnlited 23 /bin/bash -login &

These commands work for me on an HDVR2 @ 4.0.1b

Serial and ethernet bash, respectively

[Jeff D]

is what I said I did above right?

New disk with 4.0.1b installed, I moved killhdinitrd kernels to partition 3 and 6.

here may be where I made the mistake...
I told the tivo to delete everything.
Before restarting I moved all my patches and such into /dev/hda7 /var/hack
I didn't acutally run anything yet just put them on the drive for later use.

I modified the /hda7 etc/rc.d rc.sysinit.author file to startup bash and telnet (or so I thought)

But, it now occurs to me, I never checked what partition the tivo was booting from... can I do that from a mfstools boot cd?

and just to 2x check, the dlink usb->lan adapter that worked before should work on 4.0, right?

[Jeff D]

Ok, I pulled the drive. I can't find any way to get bootpage to run (no idea where it's located, i checked bin sbin tvbin on the tivo drive)

I can't actually mount /dev/hdb4 but I can mount /dev/hdb7 *hdb is the tivo drive* Is /hdb4 a 'locked' partition?

The other thing I noticed was I am missing -login from my bash startup command, I've fixed that. Everything else looks OK.

Now this drive didn't have a rc.sysinit.author file before I created it. I do see that rc.sysinit does a check if that file exists and then executes it. As long as I chmod the rc.sysinit.author file I don't need to do anything else to get it to run do I?

[The Only Druid]

Ok, I pulled the drive. I can't find any way to get bootpage to run (no idea where it's located, i checked bin sbin tvbin on the tivo drive)

I can't actually mount /dev/hdb4 but I can mount /dev/hdb7 *hdb is the tivo drive*

The other thing I noticed was I am missing -login from my bash startup command, I've fixed that. Everything else looks OK.

Now this drive didn't have a rc.sysinit.author file before I created it. I do see that rc.sysinit does a check if that file exists and then executes it. As long as I chmod the rc.sysinit.author file I don't need to do anything else to get it to run do I?
Bootpage has to be put on the tivo, I believe (or at least a properly functioning one does).

If you can mount 7 but not 4, what does that mean? If you're hacking your tivo, you should be able to figure out that this means 6/7 is the active pair, and that no kernel/OS pair has been installed in 3/4. This is why you should be thinking this stuff through a bit more and ignoring guides more too: if that were the case, you'd use bootpage to determine your active pair, and only attempt to hack that pair (including dd'ing the kernel only to that partition, instead of blindly attempting to apply it to both kernel partitions).

Yes, rc.sysinit automatically loads rc.sysinit.author. Again, this is something you should have picked up well before you started actually trying to hack your tivo. Read more info available here on the, especially in the oft-linked newbie-guide-post (which is less about guides, and more about sources of already-answered-questions).

[Jeff D]

thanks druid, I'm a linux noob, but I can follow some things on my own.

It's good to know that the drive should be using the boot partition I thought was correct. Just because I think it's right, I don't always think I'm right...

I'll check if the bash -login parameter changes anything.

BTW, I'm using a thrash disk so I'm not really worried about losing anything. This is a learning project, and I've got to say... I learn a lot every step.

[Jeff D]

Things get stranger....

I finally got the telnet working (kind of) it seems the comand I added to rc.sysinit.author to disable the firewall didn't work well. I've taken to using the other method of renaming the enable file to something else.

I'm still unable to get serial bash working, no idea on that other than I know the serial port works fine as I was using dtvcon to test the serial comm and it worked.

I'm do get a bash 2.02# prompt via telnet. Strange thing is that there's no commands I can't do things like ls and such. I'm going to look into what happened with that, but it's pretty strange to me. (crap, gotta go remount the drive RO)

I did so the superpatch and did some other patches by hand just to get the experience. That was pretty painless, great job to the guys who found all the patch points!! (that's the stuff I'm good at)

Next this gets strange, despite knowing the dtivo is downloading tons of guide data and such my box is very unresponsive. About as sluggish as the 3.1 system and old drive I started with. Several minutes to page through the system information display. It's very slow.

Thanks to all who've helped me get this far! I'm still on the learning path and I'm really curious about learning about the parts upgrade from an older version to do to my second box.

[Jeff D]

You should be able to go straight to 4.0.1b using slices to upgrade. No need to go to 3.1.1c as an interim first:

1. Get 4.0.1b slices and a 4.0.1a killhdinitrd'ed kernel & copy them to your Tivo.
2. Modify your bootpage to remove the BASH_ENV stuff at the end.
3. Flip your bootpage.
4. dbload the 4.0.1b slices
5. Edit installSw.itcl to change the "reboot" line to "exit 0" & run it.
6. When it's done, dd your killhdinitrd'ed 4.0.1a kernel over top of the newly created 4.0.1b kernel.
7. Mount your new root & copy everything you want to keep over to it (rc.sysinit - if you've made changes, rc.sysinit.author, bin utilities, etc.).
8. Edit your rc.sysinit or rc.sysinit.author to remove lines that load network drivers (4.x loads these for you), remove lines that set network parameters like IP address, etc. (also done by 4.x) and anything else that shouldn't be there.
9. Rename netfilter_enable to netfilter_notenable (or anything else you want to rename it to) so it doesn't run.
10. Double check that your bootpage settings are correct (pointing to the correct root, and the active partition is the correct one)
11. Cross your fingers & reboot.

There are some subtleties in the above instructions that deserve more explanation. The "flip the bootpage" part is required so that the installSw.itcl file doesn't drop the new software into the wrong partitions. This was a side-effect of the "Sleeper" configuration. The "copy everything to the new root" part will depend on your system. You'll have to decide what you want to move over or not. And editing rc.sysinit(.author) to account for differences between 3.x and 4.x will probably require some research. You'll probably also need to read up on dbloading slices, dd'ing kernels, etc. Other than that, the above steps should work. Anyone else see any problems with it?

-psxboy

After Bill helped me get my system running again I've been trying to get the slices installed with no luck. I also posted something like this is alphawolf's 4.01 slices thread.

Anyway, I got the slices .bz2 file and uncompressed that on the PC and FTP'd the files over to /var/packages (I didn't chmod the files as they aren't executables I didn't think I needed to. But after not working I tried that too with the same results.

I dbload using dbload.tcl and the following:
dbload.tcl component-4.0-rev.slice genre-4.0-rev.slice GZbin-19371147-1.slice GZetc-19371152-1.slice GZkernel-19371154-1.slice GZlib-19371162-1.slice GZopt-19371165-1.slice GZprom-19371171-1.slice GZsbin-19371173-1.slice GZtvbin-19371175-1.slice GZtvlib-19371207-1.slice loopset-4.0-rev.slice swsystem-19372397-1.slice utils-19371212-1.slice

Only problem is that mls /SwSoftware doesn't show the new software. I've checked with both the tivosh and tivoweb and nothing new.

Now what you say psxboy is to flip the bootpage before trying the dbload. This I haven't done, and thanks for pointing it out. I'll give that a try next. (unless someone says it's bad!)

My bash is running very slow so I'm kinda screwed as nothing is working with any kind of speed... I've got another thread about that titled slow dbload (I'd love help on that too)

The problem with the slow speed is that it seems some watchdog causes a restart sometimes during the transfers. And with the bootpage flipped that can only cause me problems, right?

[psxboy]

Now what you say psxboy is to flip the bootpage before trying the dbload. This I haven't done, and thanks for pointing it out. I'll give that a try next. (unless someone says it's bad!)
Flipping the bootpage shouldn't affect dbload. You shouldn't flip the bootpage until you have the slices dbloaded & you're ready to install the new sw with installSw.itcl - and even then, it's only if you're currently running with the "Sleeper" monte method in place.

-psxboy

[Jeff D]

Flipping the bootpage shouldn't affect dbload. You shouldn't flip the bootpage until you have the slices dbloaded & you're ready to install the new sw with installSw.itcl - and even then, it's only if you're currently running with the "Sleeper" monte method in place.

-psxboy

What exactly do you mean by "currently running"? Say I've put a killhdinitrd'd 3.1.1 kernel onto the correct boot partition connected with the real root partition.

So, I'm basically running an killhdinitrd unsleepered box. Do I still need to flip the boot page?


Also, any idea on why the dbloads don't seem to be taking? I can't get anything to show any sw but 3.1.0 and "active"

Directory listing of /SwSystem
Name Type Id Date Time Size
3.1.0-01-2-151 tyDb 2255 11/08/02 16:55 716
ACTIVE tyDb 2255 11/08/02 16:55 716

[psxboy]

What exactly do you mean by "currently running"? Say I've put a killhdinitrd'd 3.1.1 kernel onto the correct boot partition connected with the real root partition.

So, I'm basically running an killhdinitrd unsleepered box. Do I still need to flip the boot page?
No... if you're running a killhdinitrd'd system, then you don't need to flip the bootpage before installing the software. (But waaay back in the beginning of this thread, you were running a "Sleepered" system so that's why my original instructions were written with that in mind.)

I don't know why your dbloads are taking so long and why they don't show up in swsystem. Perhaps you transferred the slices to the Tivo in ascii format instead of binary? IIRC it's the swsystem slice that ties everything together & makes the entry show up in swsystem. If that doesn't get loaded correctly, nothing will show up.

-psxboy

[Jeff D]

Thanks psxboy, yeah I unsleepered the box as that was a requirement as I under it. So I won't bother with the flip yet.

Now to the binary vs text. I've transferred as binary, but who knows. Can I unzip the .bz2 file with gzip or cpio on the tivo? If so I will try that. The only thing I've been able to do is untar on the pc and go from there. The files do appear as binary files on the tivo, but... who knows what's really going on.