New SD-DVR40, should I bakup the 3.1.1c-01-2-351 image???

[sizemoremk]

Hey guys new here, and I haven't had time to read things, except that some images are higly sought after.

Should I keep the current version, and back it up ASAP?

Will it be updated automatically?

Should I unplug the phone line until I get it backeup?

Thanks, and I look forward to getting knee deep in this TIVO business!

[PlainBill]

It wouldn't be a bad idea to make a backup image using MFStools. It would be an EXCELLENT idea to copy the 3.1.1c kernel to a safe place. That will come in handy when you want to hack it.

PlainBill

[sizemoremk]

Will it update this automatically?

[PlainBill]

Yes. I tried this on a 'new' (actually a refurbished) SD-DVR40 this weekend. Let it sit for a few days hooked to the satellite, forced a daily call, and it upgraded from 3.1.1c to 3.1.1e.

PlainBill

[rfc]

It wouldn't be a bad idea to make a backup image using MFStools. It would be an EXCELLENT idea to copy the 3.1.1c kernel to a safe place. That will come in handy when you want to hack it.

PlainBill

Just where IS the kernel? And when you say copy it to a safe place, you mean in addition to simply backing up the image?

[alldeadhomiez]

Just where IS the kernel? And when you say copy it to a safe place, you mean in addition to simply backing up the image?

Um, how exactly did you hack your box without knowing where the kernel is?

Keeping a separate copy of the kernel image is helpful if it's troublesome for you to restore the backup image (e.g. don't have a spare drive, etc.).

[rfc]

Um, how exactly did you hack your box without knowing where the kernel is?

Keeping a separate copy of the kernel image is helpful if it's troublesome for you to restore the backup image (e.g. don't have a spare drive, etc.).

LOL, ADH; I haven't yet! New Samsung; First foray into Series 2 territory. I have backed up the image with mfstools and am ready for the next step (which will be to put away the original drive and expand the image to a larger one. I know that the next step after that will be to let the unit upgrade to 3.1.1e, and then I will have to patch a killhdinitred kernel to it. I just dont happen to know where exactly it is on the original drive, and thought it prudent to ask before mounting a bunch of partitions and poking around. I assume that if you can not copy the kernal from the compressed image, you must do it while mounted in the puter.

Funny question though!

ps (I did NOT stay at a Holiday Inn Express last night either!)

:D

[The Only Druid]

Well, I think you need a bit of a breakdown of the tivo filesystem.

The Tivo divides the hard drive into a large number of partitions, but only 5 are relevant:

First, partition 9 is the /var partition. It is small, and if Tivo finds that it is nearly full, it will erase and rebuild that partition from scratch. Because of this, its profoundly dumb, now that killhdinitrd allows us to avoid it, to place your hacks on this partition.

Second, partitions 3 and 6 are the kernel partitions. Why two? Because 4 and 7 are the active partitions. Wait, that didn't explain it? Bear with me for a second. Tivo maintains two 'partition sets', one being 3/4 and the other being 6/7. At any given time, only one of these partition sets is the current set (when you hack your tivo, you'll find this in the 'bootpage' section).

When you hack your tivo, one of the first steps will be to either (a) run killhdinitrd on your kernel (if you're still running 3.1.1c) or (b) to dd a pre-hacked 3.1.1c kernel to the kernel partition appropriate to your active partition (for example, if 4 is your active partition, the kernel to hack is in partition 3).

As to your direct question, no you cannot do any hacking to the image. You've got to hack the expanded image. However, you -can- create an image of a hacked drive afterwards, which would facilitate restoring to a new drive if you ever had a problem.

[alldeadhomiez]

pdisk -l /dev/hda # lists the Mac partition table from hda
bootpage -b /dev/hda # tells you which partition contains the (b)oot kernel
tivopart r /dev/hda # reads the Mac partition table on hda and informs the running kernel of partition boundaries

Since disk partitions are standard block devices, they essentially look like files to a UNIX or UNIX like kernel. Therefore you can use dd, cat, shell redirects, etc. to read and write the kernel image (or images of any other partition, if you so choose). Examples:

# tivopart r /dev/hda
# bootpage -b /dev/hda
3
# cat /dev/hda3 > /tmp/boot_kernel.img
# dd if=vmlinux-3.1.1c-killhdinitrd.img of=/dev/hda3

[rfc]

Second, partitions 3 and 6 are the kernel partitions. .

So I get an error mounting all but 7 so, I assume that the active boot partion pair is 6/7. But a "df" gives me only hda1, hdc7 and hdc9 (I tried to mount 3,4,6,7,9)?

Also, with all respect to sizemoremk, this is his thread, and I did not intend to usurp it. I can start another.

[PlainBill]

So I get an error mounting all but 7 so, I assume that the active boot partion pair is 6/7. But a "df" gives me only hda1, hdc7 and hdc9 (I tried to mount 3,4,6,7,9)?

Also, with all respect to sizemoremk, this is his thread, and I did not intend to usurp it. I can start another.
Again, refer to the pdisk -l output. Partitions 4, 7, and 9 are ext2 partitions (i.e. they have normal file systems) while 3 and 6 are image partitions - the kernel is a single file which is loaded into memory.

PlainBill

[rfc]

OK. pdisk gives me the whole shebang--all sixteen partitions. I see that 4,7 and 9 are indeed ext2.

Mounted them all.

Bootpage -b tells me that 4 is the boot partition.
Tivopart doesn't work because (I guess) the command is not on the boot cd I used (Ptv lb48 CD).

No matter. At this point, can I (and if I can,how would I) use the dd command to save a copy of the kernel image to hda1 (my primary hd), before proceeding with patching a killhdinitrd image of 3.1.1c to the new drive?

[PlainBill]

OK. pdisk gives me the whole shebang--all sixteen partitions. I see that 4,7 and 9 are indeed ext2.

Mounted them all.

Bootpage -b tells me that 4 is the boot partition.
Tivopart doesn't work because (I guess) the command is not on the boot cd I used (Ptv lb48 CD).

No matter. At this point, can I (and if I can,how would I) use the dd command to save a copy of the kernel image to hda1 (my primary hd), before proceeding with patching a killhdinitrd image of 3.1.1c to the new drive?

You're using a version of bootpage that reports the wrong boot partition. The actual boot partition is 3. Assuming the TiVo drive is Secondary master, to back it up mount /dev/hda1 as /dos, then:

dd if=/dev/hdc3 of=/dos/3.1.1c.kernel bs=1024

PlainBill

[rfc]

You're using a version of bootpage that reports the wrong boot partition. The actual boot partition is 3. Assuming the TiVo drive is Secondary master, to back it up mount /dev/hda1 as /dos, then:

dd if=/dev/hdc3 of=/dos/3.1.1c.kernel bs=1024

PlainBill

Thanks, PB. I took the original drive (after it made the call, but before 3.1.1e was downloaded) and dd'd both 3 and 6. On that drive bootpage reported 7 as the boot partition.

When you say I am using a version that reports the wrong boot partition, I thought you were referring to the problem with something in the Sleeper Iso, but I thought that reported the wrong PAIR...i.e. if it reported 6 it was 3 or if it reported 3 it was 6. Is what you refer to above that, or something different.

In any case, I did 'em both. I assumed I could name the output file anything I wanted, so I did.

I'll do the same with the 3.1.1e version from the new drive. I gots backups!

I did note that on the original drive, pdisk reported both kernel partitions at 8192 k (but 4.0M for some reason).

On the new drive--the one that called again and (I think) got the "e" version of the software it reported partion 3 at 4096 (2.0M) and partition 6 at 8192 (4.0M), but that is confusing to me because if 3 was active, why is it smaller?

Anyway, I have lots of reading to do; lots of learning to do.