stuck at powering up

[bigcat400]

Got a drive to replace the original one and be able to apply hacks (HR10-250).

I cloned the original drive to the new one fine, booted off the new one, no problems.

Put drive back on the PC to proceed to hack the kernel.

bootpage -p showed root partition on /dev/hda7, meaning kernel is
/dev/hda6.

I backed up the existing kernel before applying the new kernel from
the ptvupgrade CD.

The hacked kernel does not boot, the Tivo hangs on "Welcome ..powering up" screen forever. Restored the previously backed up kernel, and this wont
boot either now, hanging at the same place.

Checked all jumpers, connectors, all this is ok..

To make sure I did not screw up the tivo, I put in the original tivo
drive, and booted fine.

The question is what can I do now with the replacement drive.

Do I need to clone the original tivo again?

What could have possibly gone wrong?

Why didn't the backup kernel work? not sure what to do next?

The ptvupgrade CD I used is the $20 one (universal CD), that
supposedly comes with the hacked kernels, and I used the one from the
s2_kernels/3.1.5 directory.. isn't this the right one?

appreciate any help guys

thanks

[PlainBill]

By your description you didn't do anything wrong. Now it's time to give us the information to see what really happened. If you had done a little searching for similar problems, you would have found this (http://www.dealdatabase.com/forum/showthread.php?p=234467#post234467) link.

PlainBill

[bigcat400]

Thanks PlainBill, before I go the serial cable route, there's a couple of things I want to try.

- Create the clone w/ dd now instead of mfsbackup/mfsrestore. I have no reason to suspect the clone was bad since it worked until replaced its hda6 partition with a new kernel. But some guides use "dd" instead of mfs.

- Since things went wrong for me trying to use the kernel from the upgrade CD, I was wondering If I could use killhdinitrd on the original kernel. This is where I get confused a bit. I have seen info that says I can only use killhdinitrd on the 3.1.5 base kernel. However, I have seen couple of guys, including one from this site (here (http://www.dealdatabase.com/forum/showthread.php?t=37015)) that runs killhdinitrc on whatever kernel the disk happened to have, I believe the guide claims to have instructions for up to 3.1.5e.

My tivo came with 3.1.5f. Can I run killhdinitrc on this? So far my understanding was no, and I would need to find a virgin 3.1.5 kernel. But then, I have been running into these guys which do not appear to require a base 3.1.5.

Thanks for the info.

By your description you didn't do anything wrong. Now it's time to give us the information to see what really happened. If you had done a little searching for similar problems, you would have found this (http://www.dealdatabase.com/forum/showthread.php?p=234467#post234467) link.

PlainBill

[PlainBill]

I wouldn't use dd to copy the drive unless it contains recordings you want to keep. Mfsbackup / mfsrestore will only copy necessary data; dd will copy the entire drive, whick takes aLOT longer.

There are several possible things that went wrong.

1. I know the old PTVupgrade cd had kernels that had already been 'fixed' by killhdinitrd. I was under the impression that this is the case with the current version also. If the kernel was NOT modified, you could see a problem similar to the one you are experiencing.

2. Some people get creative and copy the killhdinitrd kernel to partition 4 or 7, this will wipe out the root partition.

3. Of course, having a TiVo drive hooked up when you boot a computer to Win2K or Win XP will cause problems.

You cannot killhdinitrd a 3.1.5d, 3.1.5e, or 3.1.5f kernel. Note that you can killhdiinitrd either a kernel as a vmlinux.px file, or as a kernel in the appropriate partition.

PlainBill

[eastwind]

Got a drive to replace the original one and be able to apply hacks (HR10-250).

I cloned the original drive to the new one fine, booted off the new one, no problems.

Put drive back on the PC to proceed to hack the kernel.

bootpage -p showed root partition on /dev/hda7, meaning kernel is
/dev/hda6.

I backed up the existing kernel before applying the new kernel from
the ptvupgrade CD.

The hacked kernel does not boot, the Tivo hangs on "Welcome ..powering up" screen forever. Restored the previously backed up kernel, and this wont
boot either now, hanging at the same place.

Checked all jumpers, connectors, all this is ok..

To make sure I did not screw up the tivo, I put in the original tivo
drive, and booted fine.

The question is what can I do now with the replacement drive.

Do I need to clone the original tivo again?

What could have possibly gone wrong?

Why didn't the backup kernel work? not sure what to do next?

The ptvupgrade CD I used is the $20 one (universal CD), that
supposedly comes with the hacked kernels, and I used the one from the
s2_kernels/3.1.5 directory.. isn't this the right one?

appreciate any help guys

thanksWhat is the command line you're using to backup the old kernel and to install the new kernel.

What is the output of bootpage -b /dev/hdX?

ew

[bigcat400]

Thanks folks.

* I did not mind to use dd now because I want to keep all recordings. I now have an exact copy of the original drive that boots the tivo fine. I am getting ready to replace its kernel again now.. but not sure what I can do differently from this point on.

* ew, to replace the kernel, I used the following command sequence:

# dd if=/dev/hda6 of=/mnt/c/kernels/original_vmlinux.img
# cd /tmp
# cp /cdrom/s2_kernels/3.1.5/vmlinux.px.gz .
# gunzip vmlinux.px.gz
# dd if=vmlinux.px of=/dev/hda6

This is it, as far as I know. FYI, the drive is connected as primary master to my machine. That is why it is "hda" above.

# bootpage -b /dev/hda
Boot Partition: 7

# bootpage -p /dev/hda
root=/dev/hda7 brev=0x100A

# pdisk -l /dev/hda
..
..
3: Image Kernel 1 8192 @ 268618470 ( 4.0M)
..
..
6: Image Kernel 2 8192 @ 269150951 ( 4.0M)
..
..

I can't really tell what is wrong above. I can only think about the kernel image on the upgrade CD not being compatible with my unit (if this is possible at all?). This is why I have been trying to find an image that I can killhdinird myself, but no luck so far. The ftp server "edidas?" that was posted here somewhere is not taking logins.

Do you see anything wrong?

thanks a lot

[eastwind]

Do you see anything wrong?
Only thing I'd like to see you try different is move the TiVo drive to a different position on the chain. Might still be seeing some issue early boot CDs had with /dev/hda. Try moving it.
BTW, what boot CD are you using?
ew

[bigcat400]

I am using the latest $20 universal boot CD from ptvupgrade.

It appears my latest attempt at replacing the kernel has also failed. Stuck at powering up.

I put the drive back on the PC and tried to mount the root partition:

mount /dev/hda7 /mnt/tivo (also tried mount -t ext2 /dev/hda7 /mnt/tivo)

and getting the following error:

"wrong fs type, bad option, bad superblock on /dev/hda7, or too many mounted file systems"

it seems to me... the "dd if=vmlinux.px of=/dev/hda6" is messing up the root partition ???? Does this sound reasonable?

I guess I can try moving the drive out of hda to see whether that makes any difference...

Only thing I'd like to see you try different is move the TiVo drive to a different position on the chain. Might still be seeing some issue early boot CDs had with /dev/hda. Try moving it.
BTW, what boot CD are you using?
ew

[bigcat400]

moved it to hdb, and made no difference.

The "dd" command that I am using to get the kernel into partition 6 is messing up the root partition. Proof is, I can't no longer mount partition 7 any longer.

Is there any other way to get the kernel into the drive?

Just curious, when I backup the kernel partition, it creates a 4MB image. However, the hack image from the CD that I want to get in (vmlinux.px) is 2MB only... is this OK?

Does dd need an extra parameter? sorry folks, I am just out of ideas.

When I run "dd if=vmlinux.ps of=/dev/hdb6" I get the 1+1 records in/out right away, but 5 to 10 minutes go by before I get the command line prompt back, is this normal? :confused:

I am using the latest $20 universal boot CD from ptvupgrade.

It appears my latest attempt at replacing the kernel has also failed. Stuck at powering up.

I put the drive back on the PC and tried to mount the root partition:

mount /dev/hda7 /mnt/tivo (also tried mount -t ext2 /dev/hda7 /mnt/tivo)

and getting the following error:

"wrong fs type, bad option, bad superblock on /dev/hda7, or too many mounted file systems"

it seems to me... the "dd if=vmlinux.px of=/dev/hda6" is messing up the root partition ???? Does this sound reasonable?

I guess I can try moving the drive out of hda to see whether that makes any difference...

[PlainBill]

Something very unusual is happening here. This USUALLY means a problem with computer hardware.

I suggest a systematic approach: Make a simple image using mfsbackup. I STRONGLY recommend hooking up the cables so a fat32 dive is primary master, cdrom is primary slave, and the tivo drive is secondary master.

mfsbackup -l 30 -6so /pathtobackup/hr10image.mfs /dev/hdc

Restore the image to your new drive:

mfsrestore -zpi /path2backup/hr10image.mfs /dev/hdc

Test the drive in the TiVo

See if bootpage and pdisk give reasonable results. Assuming partition 7 is the active root, dd the kernel to partition 6.

dd if=/pathtofile/vmlinux.px of=/dev/hdc6 bs=1024

Check again to see if bootpage and pdisk give reasonable results

run killhdinitrd on /dev/hdc6

Test the drive again.

PlainBill

[Wolffpack]

When I run "dd if=vmlinux.ps of=/dev/hdb6" I get the 1+1 records in/out right away, but 5 to 10 minutes go by before I get the command line prompt back, is this normal? :confused:
I've just been watching this thread. But this doesn't seem right. Your command is correct but you should get the prompt back right away.

Is you drive attached to a cached IDE controller?

As PB mentioned, I'd think this is leading to hardware.

[bigcat400]

Tried the method I have been following on a different PC and got the same results. Bad drive after "dd"ing hacked kernel.

Went back to my PC and set it up as PlainBill suggested. The first command reports an "error" as follows, though it says "success" too :confused:

tivo = secondary master
fat32 drive = primary master (30GB fat32 partition)
new drive = primary slave

# mount /dev/hda1 /mnt/c
# mfsbackup -l 30 -6so /mnt/c/hr10image.mfs /dev/hdd
Scanning source drive. Please wait a moment.
Source drive size is 281 hours
Backup image will be 281 hours
Uncompressed backup size: 4239 megabytes
Backup failed: /mnt/c/hr10image.mfs: Success

I will try to write the above image to the new drive anyway ...

Wolff, I dont know about cached IDE controllers, I guess I can do some research on this. My feeling is that the "dd" command is not doing what we are expecting it to do. My new drive is a Samsung 8MB cache. Is it possible the drive itself may be caching something??? I tested the drive w/ Samsung utilities and the drive appear to be OK. It also works with no issues as a clone. But I also agree it seems to be a hardware "thing" on either the drive or the controller that is preventing "dd" from running properly.



I've just been watching this thread. But this doesn't seem right. You're command is correct but you should get the prompt back right away.

Is you drive attached to a cached IDE controller?

As PB mentioned, I'd think this is leading to hardware.

[PlainBill]

mfsbackup -l 30 -6so /mnt/c/hr10image.mfs /dev/hdd

If drives are hooked up as you indicate, this shouldn't work. The TiVo drive would be /dev/hdc

Also, that uncompressed backup seems VERY large. While I've never tried backing up an HR10-250, most uncompressed backups are in the range of 1 Gigabyte.

PlainBill

[bigcat400]

sorry. I meant tivo is secondary slave (hdd). hdc is my CDROM. Not sure why the image is so large.

If drives are hooked up as you indicate, this shouldn't work. The TiVo drive would be /dev/hdc

Also, that uncompressed backup seems VERY large. While I've never tried backing up an HR10-250, most uncompressed backups are in the range of 1 Gigabyte.

PlainBill

[Narf54321]

Okay, it looks like you've got your drive hooked up into your PC as a slave.

Did you make sure to move the jumper back to MASTER when you put in back in the TiVo? I mean, you said you checked all jumpers but a stuck "powering up" message sure sounds like an unrecognised hard drive.

[bigcat400]

Wow.. I finally get to report good news...

I had success with the systematic approach from PlainBill, except with a different mfsbackup command:
mfsbackup -f 9999 -1so /mnt/c/hd_tivo.bak /dev/hdd
(The command posted by PlainBill kept failing for whatever reason).

Did the restore, replaced the kernel, and bingo, I could finally boot last night. Went to sleep last night smiling for the first time in two days. Wife couldn't understand what was wrong with me.

Ok, to get to the point, what has done the magic for me is adding "bs=1024" to the dd command, as suggested by PlainBill.

Since I wanted a clone of the original drive, including all recordings, I went back to my original approach of backing up the full drive (left this running last night). Then replaced the kernel using "dd if=vmlinux.px of=/dev/hdd6 bs=1024", instead of just "dd if=vmlinux.px of=/dev/hdd6". When I got the prompt right back, I knew the thing was going to work, since previously (without bs=1024) the dd used to hang for about 5 minutes.

I was just able to telnet to my tivo and ready to load the rest of the good stuff.

Thanks all for helping out. I am a very happy camper right now. Hope this helps somebody else save two or three days of misery.:D


Something very unusual is happening here. This USUALLY means a problem with computer hardware.

I suggest a systematic approach: Make a simple image using mfsbackup. I STRONGLY recommend hooking up the cables so a fat32 dive is primary master, cdrom is primary slave, and the tivo drive is secondary master.

mfsbackup -l 30 -6so /pathtobackup/hr10image.mfs /dev/hdc

Restore the image to your new drive:

mfsrestore -zpi /path2backup/hr10image.mfs /dev/hdc

Test the drive in the TiVo

See if bootpage and pdisk give reasonable results. Assuming partition 7 is the active root, dd the kernel to partition 6.

dd if=/pathtofile/vmlinux.px of=/dev/hdc6 bs=1024

Check again to see if bootpage and pdisk give reasonable results

run killhdinitrd on /dev/hdc6

Test the drive again.

PlainBill