Not sure if PROM is hacked properly or if initrd just isn't taking

[captain_video]

I just had my PROM modified by a third party and I've been trying to replace the initrd file in the kernel. I made a backup image of the drive and restored it to a 500GB drive before attempting any other hacks. The unit booted up fine when I got it back from the guy that did the PROM and it also booted fine after the drive upgrade. I made a backup copy of the kernel and then proceeded to use the replace_initrd.x86 utility posted by Nilla Zilla in the files section. I renamed the "replace_initrd.x86" file to "replace_initrd" and then used the following command:

/dos/replace_initrd /dev/hdc3 /dos/null-linuxrc.img.gz /dos/initrd.bak

The script appeared to run fine as I got a message indicating that the initrd file was found in the kernel, along with the hex location, and replaced with the file I supplied. What puzzled me was that it was followed by a list of options to use with the dd command as though it had been entered incorrectly, which makes me wonder if there's a problem with the script or if I just entered the command wrong. I've since repeated the process several times with the same results.

The S3 Tivo booted fine after performing the replace_initrd function but I don't think it actually took. I installed the tivotools.tar files in tivo-bin and added the directory to the PATH statement of my rc.sysinit.author file. I was unable to connect via telnet after reinstalling the drive in the Tivo and booting up. I haven't built my serial cable yet to do any troubleshooting. When I checked the drive in my PC again I found that the rc.sysinit.author file and the tivo-bin directory got wiped so it appears that initrd is still working.

Is there any way to confirm that the PROM mod is working as it should? I seem to recall a post indicating how to run a check on the kernel to see if it was patched properly after running replace_initrd but I'll have to go back and see if I can find it.

[Jamie]

I just had my PROM modified by a third party and I've been trying to replace the initrd file in the kernel. I made a backup image of the drive and restored it to a 500GB drive before attempting any other hacks. The unit booted up fine when I got it back from the guy that did the PROM and it also booted fine after the drive upgrade. I made a backup copy of the kernel and then proceeded to use the replace_initrd.x86 utility posted by Nilla Zilla in the files section. I renamed the "replace_initrd.x86" file to "replace_initrd" and then used the following command:

/dos/replace_initrd /dev/hdc3 /dos/null-linuxrc.img.gz /dos/initrd.bak

The script appeared to run fine as I got a message indicating that the initrd file was found in the kernel, along with the hex location, and replaced with the file I supplied. What puzzled me was that it was followed by a list of options to use with the dd command as though it had been entered incorrectly, which makes me wonder if there's a problem with the script or if I just entered the command wrong. I've since repeated the process several times with the same results.

The S3 Tivo booted fine after performing the replace_initrd function but I don't think it actually took. I installed the tivotools.tar files in tivo-bin and added the directory to the PATH statement of my rc.sysinit.author file. I was unable to connect via telnet after reinstalling the drive in the Tivo and booting up. I haven't built my serial cable yet to do any troubleshooting. When I checked the drive in my PC again I found that the rc.sysinit.author file and the tivo-bin directory got wiped so it appears that initrd is still working.

Is there any way to confirm that the PROM mod is working as it should? I seem to recall a post indicating how to run a check on the kernel to see if it was patched properly after running replace_initrd but I'll have to go back and see if I can find it.If the prom mod wasn't it place, it would refuse to boot a modified kernel. It would not show the symptoms you are describing -- it just wouldn't boot. You'd see the usual boot fail reason on the serial console (60? I can't remember anymore).

Sounds like either your initrd replacement didn't take for some reason, or you didn't dd the modifired kernel to the right partition.

I've got a custom built kernel I've been playing with, with the initrd turned off. I'll post it and the build script (a variation on this (http://www.dealdatabase.com/forum/showthread.php?t=46361)) when I feel like it is ready for prime time.

[captain_video]

Now you've got me thinking. Is the backup file created by replace_initrd the modified one or does the utility modify the kernel in place? I've been under the assumption that it's making a backup of the unmodified kernel and replacing initrd on the kernel on my Tivo drive. I didn't dd anything back over to the Tivo drive after running replace_initrd. If that's what I need to do then having the dd command options and syntax displayed after running replace_initrd now makes perfect sense. Just to be sure, what exactly is being backup when I run the program?

[Jamie]

Now you've got me thinking. Is the backup file created by replace_initrd the modified one or does the utility modify the kernel in place? I've been under the assumption that it's making a backup of the unmodified kernel and replacing initrd on the kernel on my Tivo drive. I didn't dd anything back over to the Tivo drive after running replace_initrd. If that's what I need to do then having the dd command options and syntax displayed after running replace_initrd now makes perfect sense. Just to be sure, what exactly is being backup when I run the program?I've never run it on a raw partition -- always on the kernel vmlinux.px. Perhaps it doesn't work when run on the raw partition. Second, in your command line, it looks like you are passing in the gziped null initrd. I don't think that is right either. I believe you need to uncompress it first, though I could be wrong about that.

[buechel]

what linux environment did you use to replace initrd?

I've found that the busybox version on the MFSlive.org disk isn't compatible with Mr Black's replace_initrd tool. I haven't taken the time to find out why. The "error" is exactly as you describe. DD acts like you've given an invalid command

Copy the kernel to computer and use an older non-sata linux environment such as a ptv disk. It will work in there.

[captain_video]

I was using the mfslive boot CD. I have an SATA to IDE adapter so I should be able to use my PTVUpgrade boot CD instead. I had tried running replace_initrd on the kernel I had transferred to my hard drive but I kept getting syntax errors. I'll try it with the other CD on the backed up kernel and see how it goes.

[Narf54321]

I did my init_rd replacement with Cygwin, and moved the kernel file back to the tivo drive.

I *have* used the "mips" version of replace_initrd on the 8.1.1 update, after the box was initially hacked, and it worked fine even directly against the kernel partition. Dunno about the other one.

[captain_video]

I just tried it again using the PTVUpgrade boot CD and patching the kernel I had copied over to my hard drive and it worked like a charm (after backing up the copied kernel, of course). I dd'd the patched kernel back to partition 3 and I'm back in business. I now have bash and FTP working with Alphawolf's binaries. Time to do some more reading to see what else I can throw at this bad boy. Thanks for the quick responses, fellas. You're the greatest.:D

BTW - I used the x86 version of replace_initrd because I was patching the kernel on my FAT32 drive and not on the Tivo itself.