4.x+RID - support

[hxmiller]

If you review the code, you will see that it steps though the init files in the /init. Keep in mind linux is keeping the directory sorted, therefore the lowest number goes first. You'll see one of those steps executes a monte, which loads the LBA 48 4.x kernel, replacing the 3.1.1c kernel you originally booted with. The replaced kernel starts the entire process over again (test.conf, rc.sysinit) and the original process by the first kernel is abandoned.


Riley: Its my recommendation to update your files to include the LBA48 kernel named as vmlinux.px in the init_framework.tgz file. It would appear to help minimize the mistakes and questions we are seeing.

The 2.4.18 kernel is running. The InstantCake image isn't LBA48 and thats my problem. If I have a LBA48 kernel running with the 3.1.1c monte will the mfs-backup of the image restore as LBA48? The process is quick to do the 4x RID solution.

[dong941]

Here what I did so far:

1. Restore 4.0.1b-2-02-240 on 120GB
2. bootpage -p /dev/hdc output is "root=/dev/hda4
3. dd 3.1.1c kernel to hdc3
4. killhdinitrd hdc3 - no problem
5. place the init-framework, monte and lba48 uma6 kernel file(s) into hdc4
6. Put devbin
6. mkdir hack @hdc4
7. Put back the new hd to tivo and booting went fine. Do a clear and delete.
7. put superpatch-4all at hack directory and execute ./superpatch-4all-NutKase-0.7.0.tcl and got an error :

Tmk Assertion Failure:
FsAllocateFunction, line 131 ()
Tmk Fatal Error: Thread tivosh <245> died due to signal -2
f9c51c 100df1c 100e18c 100e1dc dabe9c dab55c 400c50 108a0b0 Restarting system

After rebooting I tried anothe file this time fakecall40-1.0-5.S2.tpm and when I bash the file I got same error.

Could u pls help me.

Thank you.

[mrwalker66]

i got it! it's just as the instructions said. i was overwriting the 4.0 kernel everytime i did the install. when i changed from using zcat on /dev/hdc6 to /dev/hdc3 it worked. went from using the real kernel to the active one. thanks riley. btw whoever's image that was i used from emule. your now showing showed up...seek help.

[chrised]

The 2.4.18 kernel is running. The InstantCake image isn't LBA48 and thats my problem. If I have a LBA48 kernel running with the 3.1.1c monte will the mfs-backup of the image restore as LBA48? The process is quick to do the 4x RID solution.

Do the restore first without the "Expand MFS" option (don't have that parameter handy right now, its in the MFS documentation somewhere).

Edit: the -x parameter is the one that expands mfs to full drive capacity.

Then, boot with the LBA48 MFStools disk, and run the mfsadd -X /dev/hdx process.


OR, copy the image file from the InstantCake image onto your fat32 drive, and then boot LBA48 mfstools, and do the normal restore/expand.

[newbie]

I don't know enough to decipher your error message BUT you didn't say you remounted the partition as read/write. You have to do that before you run the superpatch file.

Here what I did so far:

1. Restore 4.0.1b-2-02-240 on 120GB
2. bootpage -p /dev/hdc output is "root=/dev/hda4
3. dd 3.1.1c kernel to hdc3
4. killhdinitrd hdc3 - no problem
5. place the init-framework, monte and lba48 uma6 kernel file(s) into hdc4
6. Put devbin
6. mkdir hack @hdc4
7. Put back the new hd to tivo and booting went fine. Do a clear and delete.
7. put superpatch-4all at hack directory and execute ./superpatch-4all-NutKase-0.7.0.tcl and got an error :

Tmk Assertion Failure:
FsAllocateFunction, line 131 ()
Tmk Fatal Error: Thread tivosh <245> died due to signal -2
f9c51c 100df1c 100e18c 100e1dc dabe9c dab55c 400c50 108a0b0 Restarting system

After rebooting I tried anothe file this time fakecall40-1.0-5.S2.tpm and when I bash the file I got same error.

Could u pls help me.

Thank you.

[dong941]

I don't know enough to decipher your error message BUT you didn't say you remounted the partition as read/write. You have to do that before you run the superpatch file.

I did mount -o remount,rw / before I executed those hacks. I hacked my hdvr2 w/ 4.0.1b a month ago w/ no problem using killhdinitrd. The only difference today is the hack for RID and I don't know what's the problem.

Thanks

[alldeadhomiez]

I did mount -o remount,rw / before I executed those hacks. I hacked my hdvr2 w/ 4.0.1b a month ago w/ no problem using killhdinitrd. The only difference today is the hack for RID and I don't know what's the problem.

Are you sure you set MFS_DEVICE and TIVO_ROOT before you ran any scripts?

BTW: for those of you who are having trouble with it, I posted some basic instructions on using bootpage, in my bootpage thread in the files section.

[hxmiller]

Is the USB support in 4.01b slower than 3.1.1c?

[dong941]

Are you sure you set MFS_DEVICE and TIVO_ROOT before you ran any scripts?

BTW: for those of you who are having trouble with it, I posted some basic instructions on using bootpage, in my bootpage thread in the files section.

Yes, I did that. What is interesting is that a month ago I used the same method when I hacked my hdvr2 w/4.0.1b and killhdinitrd w/ no problem. Now I have a problem and the only I could think is the rid hack that I'm putting on my dsr704. Anyway, I repeat the process again and still the same result.

[jasch]

1) compact for easy download from PTV_upgrade's - reduced bandwidth == reduced hosting costs == DDB coupon

Perhaps those which already payed and downloaded might be given permission to d/l the new, smaller files also.

[rc3105]

Great. Now I need to find out how to do that. I guess after all, this was not so easy to install as Riley said. Perhaps I shouldn't have contributed $200 to the bounty after all... (btw, I am not complaining because of the donation, or the hacks, but the lack of instructions to apply them). Perhaps we will see in the near future somewhere a MFS backup that already has the hacks applied...

sorry, I really have tried to make it as simple as possible. here's what I do to verify the files / steps

download all the files and burn them to a cd

run the instant cake to setup the tivo drive

reboot with the PTV_upgrade killhdinitrd lba48 nsts-framework iso and type these commands

cdrom
*mounts the framework cd on /cdrom

mkdir /tivo

mount /dev/hdc4 /tivo
mount /dev/hdc7 /tivo
*one of these will generate an error message, the other will work fine. the tivo root is now mounted on /tivo. one's not necessary but it's easier than checking which to use with bootpage

cd /tivo
gzip -d /cdrom/s2_kernels/3.1.1c/vmlinux.px.gz
*this creates the file /tivo/vmlinux.px

dd if=/tivo/vmlinux.px of=/dev/hdc3
dd if=/tivo/vmlinux.px of=/dev/hdc6
*puts the killhdinitrd'd kernel in BOTH kernel partitions. one's not necessary but it saves having to check which with bootpage

umount /cdrom
*unmounts the cd

eject the cd and insert the 1 with files

cdrom
*mounts it to cdrom

mkdir /tivo/cdrom
cp -r /cdrom/* /tivo/cdrom
*copies all the needed files to cdrom in the tivo root

cd /tivo
tar -zxvf /tivo/cdrom/init_framework.tgz
*installs the init framework complete with uma6fix

mv /tivo/tvbin/dssapp /tivo/tvbin/dssapp.orig
cp /tivo/cdrom/dssapp /tivo/tvbin/dssapp
chmod +x /tivo/tvbin/dssapp
*updates dssapp

cp /tivo/cdrom/lba48_2.4.18.px /tivo/init/vmlinux.px
*puts the lba48 uma6 kernel where the init framework expects it

mkdir /tivo/busybox
cd /tivo/busybox
tar -xvf /cdrom/tivotool.tar
*installs busybox, tivoftpd and such

now unless I've forgotten something (upto my eyeballs lately) it will boot with bash on serial. anything else can be added or configured that way (install AW's tivotools.tar, run superpatch, etc)

Perhaps those which already payed and downloaded might be given permission to d/l the new, smaller files also.

shouldn't be a problem if you get the file from the link I posted

[NutKase]

Post moved to pm.


NutKase

[rc3105]

true enough, feel free to type up a paragraph on using bootpage and I'll stuff it in the post when I get the chance. (short on time right now, stepping out the door)

[DocTauri]

FYI for anyone still having problems:

I finally figured out my problem. I had been doing all of the steps, but still couldn't get this to work. Come to find out, it was my kernel. Originally, I had downloaded the 3.1.1c kernel from the files section, and killhdinitrd'd it so that I had 2 copies, one good, one killed, apparently it was corrupt.

I copied the 3.1.1c kernel off of my RID box's original drive, then dd'd it back to the new drive, killhdinitrd'd it from the partition (i.e. killhdinitrd /dev/hdc6) and that fixed it. Everything's working.

Doc

[chrised]

I've used the new modules to get one of my rid systems running (you could say "hacked by hand"). Seems to work great. I haven't used your framework version yet. In reviewing the framework, I have a couple of questions.

011_uma6fix.init

#!/bin/bash
echo "loading uma6fix.o"
/sbin/insmod /init/uma6fix.o
sleep 2
/sbin/insmod /lib/modules/brcmdrv-rb.o
echo "finished uma6fix.sh"

rc.arch contains:

function loadBrcm () {
  local boardID=`/tvbin/GetTivoConfig 'BORD'`
  if [ "$boardID" != "" ]; then
    case $[boardID & 0xFFFFFF00] in
      $[0x000B00] | $[0x000C00])
        /sbin/insmod /lib/modules/brcmdrv-rb.o gVideoPlaybackOffset=2900 gCh1Vbv Size=81920

1. Why is the brcmdrv-rb.o included in 011_uma6fix.init when rc.sysinit will try to load it again?

2. Is the absence of parameters going to cause problems?

I'll give it a try with a fresh image later (perhaps tonight), but my first inclination is to remove the line here that is loading brcmdrv-rb.o

I also suspect that loading this so early results in a blank screen for quite a while (normally the screen is splashed right after the driver is loaded, but in this scenario its got lots of work to do before the splash code is called.