Any ideas on what could have gone wrong cloning hdvr2 4.0 drive?

[Jeff D]

I had one dtivo hdvr2 that worked ok with the slice upgrade. The other unit (as talked about here in other threads) had problems with accepting slices, this was even true of the 6.2 slices, nothing could be used in mfs partition. The box had other strange error messages about demo and such. Demo mode was not enabled.

Anyway, I backed up the good drive with mfstools
mfsbackup -f 9999 -6so tivobackup.img /dev/hdb

That went well, and the restore was fine too, with a
mfsrestore -xzpi tivobackup.img /dev/hdb
(I did do a LLF and disk tests before the first restore)

When the unit came up it looked good. I did have the hardware incompatible error, so I ran 51killer (however I suspect in this case CDE would have been a better option, as I have all the shows and passes to del which is slow...) I also ran ADH's mrv namer and things looked good.

When I restarted things didn't work quiet right. The box booted up, but after a few minutes it restarted again, I was connected via telnet and doing some things during the stage where the dtivo is getting data from the satellite... I may have had / mounted rw, but I'm not sure exactly what I was doing, I though I was just looking around the disk to see what state everything was in.

When the box came up I don't have any menu backgrounds. Seems like the image or fileset is corrupted...

Since the steps I did were pretty common and basic I'm curious if anyone has any idea what I did wrong?

I'm about to take a second pass at this with the new method of:
restore
boot
CDE
name mrv unit.

One other question on the CDE step... I can't remember exactly what is cleared, but hacks stay around, right? Or is rc.sysinit.author deleted too?

[cbm110549]

http://www.dealdatabase.com/forum/showthread.php?p=208455#post208455

[PlainBill]

Recently several of us have done tests. We have found that f 9999 usually does NOT work on a system that has been in use. I found that f 19999 seemed to work well, but l 5, or even l 50 produced a small image that had all backgrounds. How small depends on how many clips were saved.

PlainBill

[Jeff D]

Thanks guys, I'll pull the source again.

In response to the link above, my back uncompressed was 14XX on the drive and that didn't work. I'll try bumping f to 19999 and see how that works.

[Jeff D]

Ok, the -f 19999 didn't help. Menus backgrounds are still missing. Any other ideas? Is there a way I could trick the system to allow me to use the 4.01b slices I have to upgrade even though I'm running 4.01b? I would think this would get me the needed files.

EDIT: should I keep increasing the f value? FWIW, my -f 9999 and -f 1999 both had an uncompressed size of 1449MB. So, I'm not sure bumping the value up will help, but I don't know.



I searched and couldn't find what exactly is affected by the C&DAll, is it only tivo system files? Can anyone confirm a Clear and Delete All won't wipe my var or hacks?

I assume tivoapp hack will live through, but var I could understand getting wiped. I just don't want to find myself having to recreate all those files again...

[NutKase]

Ok, the -f 19999 didn't help. Menus backgrounds are still missing. Any other ideas?

Try the 'l 5' mentioned above instead of the -f 19999 and do another backup/restore.

Can anyone confirm a Clear and Delete All won't wipe my var or hacks?

It won't wipe hacks or anything that you care about from /var (although you shouldn't run things from /var anyway.) If you really care about not losing things you need to get them out of /var or you'll wake up one morning and TiVo will have decided that you needed some /var house cleaning...


NutKase

[Jeff D]

Thanks nutkase, I'll give that a shot. I missed bill's comment on l5

On the vars things, I agree with what you say. Can't figure out why some things NEED to live there.... I'll move what I can.

[NutKase]

Thanks nutkase, I'll give that a shot. I missed bill's comment on l5

On the vars things, I agree with what you say. Can't figure out why some things NEED to live there.... I'll move what I can.

/var = partition 9 (as in /dev/hda9) mounted into the file system as /var.

It is mounted rewritable (rw) since some programs/logs etc need to write.

As far as hacking goes... I think only mfs_ftp needs to be loaded into /var. TivoWebPlus writes logs in /var but if you lose them no biggie.

Regarding mfs_ftp, you can do a little editing and run it from the / partition and the directory of your choice (I use /hack) by just always leaving your / partition as rw. I've been running that way for almost 3 years and never had to 'mount -o remount,rw /' all the time. Many might advise against it but I've saved a lot of typing :) and never lost anything.


NutKase

[Jeff D]

Nutkase, yeah I've read about editing the mfs_ftp binary to change that. I guess I'll do the same.




I've got a bit of an issue that doesn't seem to be listed here anywhere...

on the -l 5 image restore I get a
"Error restoring MFS data" message.

I don't know if the backup is screwed, the drive is screwed or what. My restore command is the same as above:
mfsrestore -s 127 -xzpi image.bak /dev/hdb


the backup was created with:
mfsbackup -l 5 -6so image.bak /dev/hdb

I don't know if increasing 5 to 50 or some other larger would help. It seems this is a problem with the backup, yet everything reported fine. One thing to note was the uncompressed size was 1340MB, 109MB less than the -f 9999 (or 19999) backups.

[NutKase]

mfsrestore -s 127 -xzpi image.bak /dev/hdb

You may need to leave out the '-s 127' since you've already created the swap.


NutKase

[Jeff D]

You may need to leave out the '-s 127' since you've already created the swap.


NutKase

Same results. =(

I did also try to increase the stream size tried both 50 and 25, both fail on the restore as the restore image is larger than the drive. Now, the restore drive is slightly smaller, and I understand how that could be an issue. But, I didn't think I was backing up enough to make a difference that would cause a problem. I guess that's not the case....

Man, I always run into these "slightly odd" problems. I have a feeling this one will end up like the others... unfixable.

I'm still open to other ideas

EDIT: Let me ask this... -f and -l operate differently? The source drive was originally a 40GB drive expanded to 80. It seems that mfs tools knows this and will work with the 80 as if it's a 40. Therefor the -x in the restore should work after all other partitions are created. But with the -l option this doesn't seem to matter, is that correct? The mfstools readme didn't go into the differences regarding this. I also didn't get a search on this yet, but I'm off to try now.

[PlainBill]

One of the restrictions we have is there in no way to automatically resize mfs partitions. (Recordings, background loopsets, etc are stored in the mfs partitions). The closest we can come to that is with the -s switch of mfsbackup. If a partition contains nothing to be saved and you used the -s switch to back it up, the partition will be eliminated. Note the mfsbackup doesn't shuffle things around - if the added partition on an expanded drive has only a single 1 meg loopset, the entire partition will be kept.

My usual comment to someone who is encountering this problem is to point out that 120 Gig drives are now selling for under $50 after rebate.

PlainBill

[Jeff D]

My usual comment to someone who is encountering this problem is to point out that 120 Gig drives are now selling for under $50 after rebate.
PlainBill
yeah, you don't know how many times the same though crosses through my mind. Too bad cash is at a premium at the moment... =(

There's also that this is a learning process, too bad all the trial and error is anti-my-learning-process as doing it once usually cements it in place. I've now done a bunch of stuff that's "locked in".

I'm giving another try with bumping the -f option up, although I don't know if it will help as there may be no other files that can be included. I honestly don't know, but I'll give it a shot.


Is there really no way I can trick the system to install another 4.01b to the other boot/root partitions and run that vs. the bad 4.01b that's on the current boot/root pair?

[NutKase]

Is there really no way I can trick the system to install another 4.01b to the other boot/root partitions and run that vs. the bad 4.01b that's on the current boot/root pair?

I've almost forgot what you're trying to do and I'm not going to take the time to read back...

Just 'from the hip' you CAN dd the root and kernel partitions from a working 4.0.1b setup to the other pair and flip and reset the bootpage to it also. I used to back up a two partition NON_SLEEPER monte that way. Works fine but may not be what you want.

This 'other' drive needs something to setup the mfs though, like restoring to it or copying and entire drive etc.


NutKase

[Jeff D]

For you guys with a clue care to speculate on this one?

I did another image with -f 2999 just for the hell of it, same results 1449MB backed up. Restored that to the bedroom drive.

Tried the bedroom drive in the livingroom tivo (source of the image) and sure enough the menus were gone. Confirmed it's not something specific to the bedroom tivo.

Took the drive out of the livingroom tivo and returned it to the bedroom tivo.

Guess what... the menus now have backgrounds! I don't get it, I have no clue as to why that could happen.

I'm doing a C&D all on that box to wipe passes, recordings and other stuff. We'll see if the backgrounds stay through that.

[PlainBill]

Jeff, just to answer an earlier question, yes it is possible to create an identical software installation in the alternate partition set. Note that this may not help - The software partitions contain just that - the software. A significant amount of information is in the MFS partitions, having a second copy of the software won't solve a database error.

To do this, you must have access to the TiVo, either serial bash or telnet will work. Mount the active root r/w, then edit /tvbin/installSw.itcl, and make the following changes:

Change this line: if { ! [FSafeToInstall $name] } {
to this if { [FSafeToInstall $name] } {

If you want to hack the new partition, also change reboot to exit 0 , then save and exit the editor.

Check the version of the software installed echo mls /SwSystem | tivosh Note that the active software matches one of the entries above; for example 3.1.1e-01-2-381 .

Run the installation, using that version number installSw.itcl 3.1.1e-01-2-381

When it completes, hack the new partition set and reboot.

PlainBill

[Jeff D]

arrrgh, "transparent menu" that would have helped... sucks not knowing what to search for!

Bill, I'll give it a shot, but from what you said and what I've read it makes sense that the streams won't get updated.

The only thing I can hope is that maybe the sytem can be tricked into thinking it's 3.x so those video files get updated. I'll give it a shot.

[Jeff D]

I was able to install 4.01b again but not with the edit provided.

I needed to change:
if [catch {$swsys loadFromDB $dbHandle $name} res] {
putlog "No software found in db for \"$name\", $res"
} else {
if { $emergency == 1 || [$swsys isActive] == 0} {

to:
if [catch {$swsys loadFromDB $dbHandle $name} res] {
putlog "No software found in db for \"$name\", $res"
} else {
if { 1 || $emergency == 1 || [$swsys isActive] == 0} {



I did all the other patching I'd need and still the same problem.
I'd be willing to try again with setting the system version to a 3.1x version, I might try the 3.1.1e listed above...

I'll also look into the script for copying resources from ADH's creating the MFS partition from scratch.

Bill, sorry for having you repeat yourself. Once I found what to search for I see you've made lots of suggestions previously. Proof I'm the worlds worst searcher, not for lack of effort.... just poor use of words to search on.