In-place kernel upgrade

[Throg]

When I got 7.3.1, I think I used the 3.1.5 kernel. I decided at one point that I wanted to switch to the 7.2.2 kernel instead and thought I could just dd it over the existing. It didn't work. Turned my tivo into a boat anchor. I suppose it's possible that I botched the command but unlikely because I'm usually very careful when I'm typing and normally proofread what I've done before hitting enter.
So, my question is: What is the procedure for replacing the kernel on an already hacked and working box? Or do I even stand to gain anything by making this change?

[cheer]

When I got 7.3.1, I think I used the 3.1.5 kernel. I decided at one point that I wanted to switch to the 7.2.2 kernel instead and thought I could just dd it over the existing. It didn't work. Turned my tivo into a boat anchor. I suppose it's possible that I botched the command but unlikely because I'm usually very careful when I'm typing and normally proofread what I've done before hitting enter.
So, my question is: What is the procedure for replacing the kernel on an already hacked and working box? Or do I even stand to gain anything by making this change?
Exactly what you said you tried -- dd it over the old one. So despite your proofreading, you've almost certainly typo'd something. Hard to tell without a boot log.

[ocntscha]

When I got 7.3.1, I think I used the 3.1.5 kernel. I decided at one point that I wanted to switch to the 7.2.2 kernel instead and thought I could just dd it over the existing. It didn't work. Turned my tivo into a boat anchor. I suppose it's possible that I botched the command but unlikely because I'm usually very careful when I'm typing and normally proofread what I've done before hitting enter.
So, my question is: What is the procedure for replacing the kernel on an already hacked and working box? Or do I even stand to gain anything by making this change?Less detail on how you go about doing things and more detail on what you actually did would be useful.

Maybe you transferred the kernel onto the Tivo with FTP and didn't do a binary transfer?

Maybe you got a gzipped 7.2.2 kernel and didn't uncompress it before dd'ing it over the old one?

[Throg]

Maybe you transferred the kernel onto the Tivo with FTP and didn't do a binary transfer?It was transferred in binary. Everything my ftp client transfers is binary.
Maybe you got a gzipped 7.2.2 kernel and didn't uncompress it before dd'ing it over the old one?It is/was uncompressed.

I think Cheer is probably right if indeed it is that simple. But I do appreciate all feedback.

What I did was this:
1. ftp 7.2.2 vmlinux.px.gz to /var/hack/killhdinitrd. It was already +x
2. decompressed (gzip -d vmlinux.px.gz)
3. dd if=vmlinux.px of=/dev/hda3 (currently active partition)

[ScanMan]

Just a quick question since it's not clear; you are using the '7.2.2-oth-K1' kernel and not a generic 7.2.2? Because the 'oth-K1' is the specific kernel susceptible to killhdinitrd.

[Throg]

Just a quick question since it's not clear; you are using the '7.2.2-oth-K1' kernel and not a generic 7.2.2? Because the 'oth-K1' is the specific kernel susceptible to killhdinitrd.Yes. The one on the PTVUpgrade CD.

[ScanMan]

Yes. The one on the PTVUpgrade CD.Figured; just thought I'd ask. Strange, a normal dd should work w/out problems. AFAIK, the only thing you gain with the 7.2.2 is DHCP support, which you can easily hack into the 3.1.5 by loading the 'af_packet.o' module. I've been debating upgrading to the 7.2.2 as well but haven't really found a compelling reason yet...

[Narf54321]

Strange. You could always just dd your 3.1.5 kernel back and get the tivo unit working again. Maybe its something stupid and subtle, like you need to zero-out the boot partition before copying - you know, remove any possible 'junk' in the boot partition.

I don't think there are any 'locks' on the boot partition, once its up and running, so overwriting the active boot (while its running) shouldn't be this hard.

[mr_zorg]

It's not. I did this exact thing (upgraded to 6.3 with a 3.1.5 kernel, then later dd over a 7.2.2 kernel) a week or two ago and it worked just fine. Who know what happened in this case.