bootpage contradictions

[jbuehl]

I'm trying to get HMO working on my HDVR2 without hacking the kernel (yet). I downloaded a copy of bootpage from Erik Rainey's site and I'm trying to use it to flip the boot partitions after copying a 4.0.1a kernel to the alternate partition. Contrary to what this post says http://www.dealdatabase.com/forum/sh...ad.php?t=30688 bootpage is reporting the boot partitions as 4/7 on the virgin tivo disk:

# bootpage -a -b -p /dev/hdc
Alt Partition: 4
Boot Partition: 7
root=/dev/hda7

To copy the kernel I do this:

# tivopart r /dev/hdc
# dd if=vmlinux-4.0.1a.px of=/dev/hdc4
3203+1 records in
3203+1 records out


When I flip the partitions it appears to work correctly:

# bootpage -f -C /dev/hdc
Writing new bootpage to "/dev/hdc"............. <snip> ....done
# bootpage -a -b -p /dev/hdc
Alt Partition: 7
Boot Partition: 4
root=/dev/hda7

However when I try to boot the Tivo it repeatedly resets after displaying the initial powering up screen for a while. I also tried changing the parameter in bootpage to point to the other root partition:

# bootpage -P "root=/dev/hda4" -C /dev/hdc

but this resulted in the same behavior. After flipping the boot partition back to the (presumably) untouched kernel, it still hangs which probably indicates that bootpage is clobbering something.

There's more than one question here...

Am I using bootpage properly?
If so, do I have a buggy version? (source is dated Apr 10, 2003)
Is there a better way to do what I'm trying to do?

[jbuehl]

Actually, I'm copying the kernel to /dev/hdc3, not /dev/hdc4. I just made a typo in the post.

[Jamie]

Actually, I'm copying the kernel to /dev/hdc3, not /dev/hdc4. I just made a typo in the post.

There is supposed to be a buggy bootpage program floating around. See this. My guess is you have one of them. I have a bootpage I compiled from the tridge @ samba.org source that has worked well for me so far.

You can always run bootpage on the tivo itself. Here's its synopsis, along with a pointer to tridges version (source and x86 binary).

[jbuehl]

Thanks. That version behaves much better.

Unfortunately, I don't think that is my problem. I restored the disk from my backup and verified that it booted from the original kernel. Then I copied the active kernel partition to a backup file to possibly avoid having to restore the whole disk again:

# dd if=/dev/hdc6 of=hdc6.bak

Next, I copied the 4.0 kernel into the active kernel partition (hdc6) using dd as I posted earlier:

# dd if=vmlinux-4.0.1a.px of=/dev/hdc6

but this time I didn't flip the partitions or do anything else that would write to the disk. When I boot the tivo it shows the "Welcome. Powering up..." message for about 40 seconds, then the TV loses sync for a second, and the cycle repeats.

I have tried copying 3 different kernels to the same partition, including the one I backed up earlier and all behave the same way. To attempt to verify that the kernels were not corrupt, I ran killhdinitrd on the partition and it said it was successful.

I'm using tivopart to be able to access the tivo disk under a 2.6 kernel (Fedora Core 2).

# tivopart r /dev/hdc

Is that possibly corrupting something on the disk? I was under the impression that it only messed with memory, but maybe I missed something.

I guess the next thing I'm going to try is to get the serial port going to maybe see some boot output, but I don't have the right cable tonight, so I'm going to bed for now. In the meantime if anyone has a suggestion for what is happening, i would appreciate it.

[jbuehl]

... is it maybe a byteswapping issue?

I gave up on booting from the FC2 disk and used the mfstools2 CD. Still the same thing: I restore the disk and it boots in the tivo just fine, but the minute I do anything to the active kernel partition it's toast. No matter which kernel I copy to it, I can run killhdinitrd which terminates successfully and reports the version of the kernel I expect to see. I reasoned that if the data was being read and written to the partition backwards this would still work even though the tivo couldn't read it.

So I tried passing "swap" to the mfstools2 kernel, thinking that this had something to do with byteswapping (it's pretty clear in the prompt) and that had the astounding effect of booting the mfstools kernel and then immediately booting my FC2 kernel. ??? Does "swap" mean "swap the boot disk"? I don't think so...

[alldeadhomiez]

Edit: moved to Files section

old post follows:

I have attached the bootpage code I am using. Changes from the old version:

- fixed off-by-one on kernel partitions
- changed some outputs to match TiVo bootpage
- added byteswap auto-detection
- improved (?) command line parsing
- other minor fixups, probably introduced more bugs

This should support a lot more of the original bootpage options than the tridge code.