Backup/Restore Hacked Image (Confused)

[Audiophile]

OK, I've hacked my unit using "4.x RID/Non RID" guide by HUGE. Works great eveything is great. Hack, etc. Now, before I goto 6.2 I want to backup the image I have in-case I mess up. Based on some of the posts, I've read, I AM REALLY CONFUSED!!! Checkout this thread...

http://www.dealdatabase.com/forum/showthread.php?p=125707&highlight=mfsbackup+options#post125707

Can I just backup the image and restore it at will? Can it be done to a monte'd drive? Do I have to use the "dd" command?

Well, I tried it... :( It didn't work! Here i the backup command I used:

mfsbackup -f 9999 -6so /mnt/dos/tivo.bak /dev/hdc

Here is the restore command:

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdc

These command are taken from the HINSDALE guide. I don't want to use the "dd" command... ThenI would have to hold a complete drive just for an image. My goal is to have various stages of my hacks as images. Being able to return to a certain stage would be great. Just call up the image file I want. The posts on the site are very confusing on this matter. I understand most things about hacking my unit.

Spec...
Philips DSR704 (RID)

[ttodd1]

Well for one either you forgot a '/' in your mfsbackup or added one in your mfsrestore. Second, maybe some insite as to how you have/had the drives attached would help. Third, what error message did you get would be good to know.

[Audiophile]

Not sure what you mean about the "/"...

I don't want to give the impression that the restore did not completem it did. 100% My drive configuration is based on that is outline in th HINSDALE guide.

The problem comes when I put the unit back into the Tivo (DSR704) I get caught in a boot loop. "Welcome...Powering up" Loop, Loop, Loop! Before doing the restore everything was great the unit worked like a charm. So I can only conclude that my backup is wrong. Any help?

[PlainBill]

OK, I've hacked my unit using "4.x RID/Non RID" guide by HUGE. Works great eveything is great. Hack, etc. Now, before I goto 6.2 I want to backup the image I have in-case I mess up. Based on some of the posts, I've read, I AM REALLY CONFUSED!!! Checkout this thread...

http://www.dealdatabase.com/forum/showthread.php?p=125707&highlight=mfsbackup+options#post125707

Can I just backup the image and restore it at will? Can it be done to a monte'd drive? Do I have to use the "dd" command?
A properly made image can be restored repeatedly. Mfsbackup will not properly back up a 'two partition monte' such as used by TiVoScripts (AKA Sleeper's Iso). It will work with an in line monte such as described by NutKase.

Well, I tried it... :( It didn't work! Here i the backup command I used:

mfsbackup -f 9999 -6so /mnt/dostivo.bak /dev/hdc

Here is the restore command:

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /hdc

These command are taken from the HINSDALE guide. I don't want to use the "dd" command... ThenI would have to hold a complete drive just for an image. My goal is to have various stages of my hacks as images. Being able to return to a certain stage would be great. Just call up the image file I want. The posts on the site are very confusing on this matter. I understand most things about hacking my unit.

Spec...
Philips DSR704 (RID)
Unfortunately, Hinsdale was written for the Series 1 systems, and updated only slightly for Series 2. The backup command above will not make a good image. mfsbackup -f 19999 -6so /mnt/dos/tivo.bak /dev/hdc will work better. I prefer to use mfsbackup -l 50 -6so /mnt/dos/tivo.bak /dev/hdc which will produce a slightly smaller image.

Your restore command is also incorrect. It should be:

mfsrestore -s 127 -xzpi /mnt/dos/tivo.bak /dev/hdc

Be aware that Linux is very intolerant of typos. One mistake and you will be having a VERY bad day. As has already been mentioned, when requesting help saying "It didn't work" only tells us you made a mistake - which we already knew. The exact error message will help us help you.

PlainBill

[eastwind]

Not sure what you mean about the "/"...

I don't want to give the impression that the restore did not completem it did. 100% My drive configuration is based on that is outline in th HINSDALE guide.

The problem comes when I put the unit back into the Tivo (DSR704) I get caught in a boot loop. "Welcome...Powering up" Loop, Loop, Loop! Before doing the restore everything was great the unit worked like a charm. So I can only conclude that my backup is wrong. Any help?
What ttodd1 means is that you didn't tell us about what you had mounted, but if you didn't remount the dos drive you added or left out a '/' in one of the commands:

/mnt/dos/tivo.bak != /mnt/dostivo.bak

BTW, != means 'is not equal to'

Sometimes the reboot loop is a symptom of a hardware problem--namely a slightly disconnected ribbon cable from the main board to the power supply or to the front panel.

ew

[Audiophile]

PlainBill, Thanks for the help. Do you have any other thoughts?

I tried both backup command given in the above post. Both fail with the same result. Boot Loop! (Sounds like a new cereal :) ). I even went so far as to try a new out of the box drive to make sure it wasn't the hardware. I made sure all connection were secure...and nothing.

I'm using the hack methods outlined here: http://www.dealdatabase.com/forum/showthread.php?t=39354

I am not using the Sleeper Iso.

Can anyone point me to something that I might be missing. Do I have to set the "Bootpage" or anything like that after I restore?

[PlainBill]

A restored image should work without any problems; the only possible change would be the drive jumper.

I'd suggest either capturing the serial console output (http://www.dealdatabase.com/forum/showthread.php?p=234467#post234467) and attaching it, or pulling the drive and attaching the kernel log file (/dev/hdx9/log/kernel). Troubleshooting 'reboot loop' problems without the failure information has been compared unfavorably to searching for a black cat in the dark - when the cat is hiding in the next room.

PlainBill

[Audiophile]

Ok, use the link below to get the file:

https://www.cattenhead.com/tivo/kernel.txt

You also mentioned "drive jumpers" I've never had ti change my jumper setups. My drive are placed in the PC so I don't have to do that.

[PlainBill]

OK, this stands out:
Mar 21 01:58:38 (none) kernel: WATCH: phys addr = 0x2143400
Mar 21 01:58:39 (none) kernel: Starting Recorder
Mar 21 01:58:39 (none) kernel: Illegal read at 00000008
Mar 21 01:58:39 (none) kernel: do_page_fault #2: sending signal 11 to myworld(163)
Mar 21 01:58:39 (none) kernel: $0 : 00000000 b001bc00 7ff0f8d0 00000000
Mar 21 01:58:39 (none) kernel: $4 : 7ff3a200 00000000 00000131 00000000
Mar 21 01:58:39 (none) kernel: $8 : 00000001 010c199c 00000000 00000000
Mar 21 01:58:39 (none) kernel: $12: 00000000 ee6b2800 00000000 ba8c714c
Mar 21 01:58:39 (none) kernel: $16: 00000000 7f5673dc 00000000 00000100
Mar 21 01:58:39 (none) kernel: $20: 00000000 00021004 7ff3a200 00021005
Mar 21 01:58:39 (none) kernel: $24: 00000000 00fc7cb0
Mar 21 01:58:39 (none) kernel: $28: 1005eb60 7fff6620 00010014 00fa859c
Mar 21 01:58:39 (none) kernel: epc : 00fc7e5c
Mar 21 01:58:39 (none) kernel: Status: a001bc13
Mar 21 01:58:39 (none) kernel: Cause : 00000008
Mar 21 01:58:39 (none) kernel: 80019be8 80019cac 8001dc8c 8001de30 8001c818 00fc7e5c
Mar 21 01:58:39 (none) kernel: 00fc7e5c 00fa859c 00a6ceb8 00a6cd48 00a69bb0 00a68260 00a60a6c 00a608d8
Mar 21 01:58:39 (none) kernel: 00a60d24 00a5e180 00a5e008 0100e02c 0100e18c 0100e1dc 006cdcb8 00400e08
Mar 21 01:58:39 (none) kernel: 0108a0b0
Mar 21 01:58:39 (none) kernel: Tmk Fatal Error: Thread myworld <163> died due to signal 11
Mar 21 01:58:39 (none) kernel: pc 0xfc7e5c status 0x8001bc13 cause 0x000008 bva 0x80400000 hi 0x000068 lo 0x6e3242
Mar 21 01:58:39 (none) kernel: R00 0x00000000 R01 0xb001bc00 R02 0x7ff0f8d0 R03 0x00000000
Mar 21 01:58:39 (none) kernel: R04 0x7ff3a200 R05 0x00000000 R06 0x00000131 R07 0x00000000
Mar 21 01:58:39 (none) kernel: R08 0x00000001 R09 0x010c199c R10 0x00000000 R11 0x00000000
Mar 21 01:58:39 (none) kernel: R12 0x00000000 R13 0xee6b2800 R14 0x00000000 R15 0xba8c714c
Mar 21 01:58:39 (none) kernel: R16 0x00000000 R17 0x7f5673dc R18 0x00000000 R19 0x00000100
Mar 21 01:58:39 (none) kernel: R20 0x00000000 R21 0x00021004 R22 0x7ff3a200 R23 0x00021005
Mar 21 01:58:39 (none) kernel: R24 0x00000000 R25 0x00fc7cb0 R26 0x011bb698 R27 0x00000000
Mar 21 01:58:39 (none) kernel: R28 0x1005eb60 R29 0x7fff6620 R30 0x00010014 R31 0x00fa859c
Mar 21 01:58:39 (none) kernel: F00 0x41662464cccccccd F02 0x0000000000b12326
Mar 21 01:58:39 (none) kernel: F04 0xffffffffffffffff F06 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F08 0xffffffffffffffff F10 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F12 0xffffffffffffffff F14 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F16 0xffffffffffffffff F18 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F20 0xffffffffffffffff F22 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F24 0xffffffffffffffff F26 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: F28 0xffffffffffffffff F30 0xffffffffffffffff
Mar 21 01:58:39 (none) kernel: csr 0x001004 eir 0x005410

I'd suggest searching on the highlighted text and see if you find anything helpful. Otherwise, it's out of my league.

PlainBill

[Audiophile]

Well,

After doing som searching, the only things I can come up with are as follows...

Many posts talked about crashes in the Tivoapp come from bad patches. Check out this (http://www.dealdatabase.com/forum/showthread.php?p=248330#post248330) thread. I'm not convisnced this is an issue. Since I am doing a backup and a restore from a drive that works great.

Also, while searching for the error message listed about, I ran across some posting about the backup/restore process. Like this one (http://www.dealdatabase.com/forum/showpost.php?p=251999&postcount=10). PlainBill talks about changing the type of backup command being used. I tried this command:

mfsbackup -Tao -6so /dos/tivo.bak /dev/hdc

this gave me a larger backup file. Here is the restore command used:

mfsrestore -s 127 -xzpi /dos/tivo.bak /dev/hdc

The restore command would run 'till about 80%. Then it would fail. I was loosing it last night so I got some sleep.

After I got up this morning, I was looking at things again. I realized since the source drive is a 200GB and the destination is a 200GB, why would I use the "expand" command again. This is also noted in this (http://www.dealdatabase.com/forum/showpost.php?p=251792&postcount=6) post. Well, I'm at work right now, so I can't try the resore without the "expand". When I get home, I will try the following restore command:

mfsrestore -s 127 -zpi /dos/tivo.bak /dev/hdc

I'm not sure of one thing here, since the source drive had swap (127) applied when it was restored, do I need it here? Remember both drives are the same size and the source drive has been hacked. The original image used to start was the instantcake 4.0b image.

Can anyone think of ny other restore/backup commands that I might be missing?

[eastwind]

Check dmesg to see if the number of sectors on the destination drive is at least as large as the source. All 200GB drives are not created equal. Actually they are, but some are a little more equal than others. If the source is larger it could cause a problem with the restore (although I think you'd get an error about not enough room on destination).

The other thing to make sure of is that both drives are being recognized properly. Some BIOS/Boot CD combinations don't properly recognize >137 GB drives.

Try setting the jumpers on the drives specifically to where they are hooked up. Cable select is sometimes a problem for certain hardware/OS configurations.

Don't try to back up all streams (-Tao) unless you're piping the output to the other drive. It could make the backup too large to fit on an FAT32 drive.

Try your backup and restore without using Primary Master for TiVo drives.

ew

[Audiophile]

OK here we go again...

I managed to get home during lunch time and try some things. I tried the following command:

hda = FAT32 (20gig scratch drive)
hdb = 200gig New Maxtor (Being used as a destination)
hdc = 200gig Maxtor (4.0b Instantcake Image with hacks, works great)
hdd = CDROM (LBA48 from PTVUpgrade)

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hdb

I then issued a:

umount -f -a -r
halt

I removed the drive (hdb) and put it into the Tivo (DSR704). NOTHING It just showed "Welcome...Powering" I waited for a few minutes to make sure... NO GO. I then tried my "good" hacked drive to be sure it was OK. Everything was good.

The next thing I tried was the followng backup/restore commands:

mfsbackup -Ta -6so /dos/tivo.back /dev/hdc

mfsrestore -s 127 -zpi /dos/tivo.bak /dev//hdb

Like I mentioned in my previous post, I didn't want to use the "expand" again. This command failed during the restore process. At about 80% during the restore process. I think maybe my FAT32 drive I use to store the image on could be bad. To make sure, I reformated ti with a FAT32 boot disk. I got the same result during the MFSRESTORE. 80% and failure.

Originally Posted by eastwind
"Try your backup and restore without using Primary Master for TiVo drives."



Can you explaint his one a bit. I know what you mean about master/slave. What I'm asking is how does /aster/slave jumper setting or even where it appears on the ribbon cable change thing? This might help me if I understood.

[rpl]

hda = FAT32 (20gig scratch drive)
hdb = 200gig New Maxtor (Being used as a destination)
hdc = 200gig Maxtor (4.0b Instantcake Image with hacks, works great)
hdd = CDROM (LBA48 from PTVUpgrade)

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hdb

I then issued a:

umount -f -a -r
halt

I removed the drive (hdb) and put it into the Tivo (DSR704). NOTHING It just showed "Welcome...Powering" I waited for a few minutes to make sure... NO GO. I then tried my "good" hacked drive to be sure it was OK. Everything was good.
You need to change your HD jumper. Your new drive is either set at cable select or slave. When you move it to your tivo change the jumper to master.

[rpl]

BTW you will still need to expand the drive. The backup command will compress your image and you'll probably see a 40 or 80 gig being reported by tivo when you finally get your new drive working. Just run the expand command as outlined in Hinsdale's guide.

[Narf54321]

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hdb

I removed the drive (hdb) and put it into the Tivo (DSR704). NOTHING It just showed "Welcome...Powering" I waited for a few minutes to make sure... NO GO. I then tried my "good" hacked drive to be sure it was OK. Everything was good.

This one should've worked. As rpl says, your /dev/hdb drive is a slave, so you need to fix the jumpers back to Master when putting it back in the TiVo.




The next thing I tried was the followng backup/restore commands:

mfsbackup -Ta -6so /dos/tivo.back /dev/hdc

This command failed during the restore process. At about 80% during the restore process.

I don't think using the 's' option with mfsbackup is a good idea. That tells mfstool to smallify the MFS partitions from your tivo, which I don't think works very well. I personally use the command like so, with good results: mfsbackup -Ta6o tivobackup.bak /dev/hdc



Can you explaint his one a bit. I know what you mean about master/slave. What I'm asking is how does /aster/slave jumper setting or even where it appears on the ribbon cable change thing? This might help me if I understood.

IDE drives share the data bus (i.e. they share the same data lines on the ribbon cable). The Master and Slave settings tell the drives which drive should be listening to the current transmission (the other drive will ignore the passing data). When two devices wasn't enough in PCs anymore, they came up with a second ribbon cable setup, and thus Secondary Master and Secondary Slave appeared on PCs everywhere. If the drives aren't jumpered correctly on a ribbon cable as Master and slave, they will both try to react at the same time to data being passed down the cable.

The 'order' of drives is
(1) Primary Master (hda)
(2) Primary slave (hdb)
(3) Secondary Master (hdc)
(4) Secondary Slave (hdd)

Often when hacking a tivo, you need to fit a lot of drives in your PC at once (new drive, original Tivo drive, scratch drive) so you have to change the drive jumpers around to get them all recognized. In your PC, you had the 'new' drive as a slave device, so make sure you put the 'new' Tivo drive back to Master when it goes in the Tivo chassis, or it will ignore when Tivo tries to talk to it.

Also, a serial console cable will greatly help figure out what's going wrong.

[Narf54321]

Oh another thing, since you're working with two 200G drives you could just boot the LBA48 CD and use dd:

dd if=/dev/hdc of=/dev/hdb

[eastwind]

Can you explaint his one a bit. I know what you mean about master/slave. What I'm asking is how does /aster/slave jumper setting or even where it appears on the ribbon cable change thing? This might help me if I understood.
The reason I said to try not to use the Primary Master was because some of the original boot CDs set the Primary Master different from all the other drives with regard to byteswapping. Might or might not be an issue, but if you don't use Primary Master for a TiVo drive it won't be a problem for you.

ew

[Audiophile]

Thanks for the info, I will give it a try this evening.


Originally Posted by Narf54321

Oh another thing, since you're working with two 200G drives you could just boot the LBA48 CD and use dd:

dd if=/dev/hdc of=/dev/hdb



Id didn't want to use the Disk Copy routine because I want to keep copies of the various stages of my hacks. This allows me to play around. Then I don't have to keep one drive just for a single backup image.

I will give the is one a try: mfsbackup -Ta6o tivobackup.bak /dev/hdc

[PlainBill]

If it hasn't already been mentioned, what are the sizes of the two drives? I know you said they are both 200 Gig, but unless the target drive is at least the same size (in sectors), this will not work.

Also, did someone mention possible hardware (computer) problems can cause these problems?

PlainBill

[Audiophile]

PlainBill,

Funny you mention that (computer issues) I found that the motherboard/bios I was using did not correctly recognize the UDMA 6 drives I have. (200 Gig) The previous motherboard were recognized as UDMA 4 (80 gig) drives. I put in a new board and everything looked like it should. I then tried this command: mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hdb
.

That didn't work. (When I put the restored drive into the Tivo, it just sat at "Welcome...") I decieded to start again. Since the did the original drive unser some strange drive geometry, I better start the process again with the correct geometry.

I'm getting some different opinions on the Backup restore command... (use -s, don't use -s). Not sure where to go.

[PlainBill]

For a backup to an image I recommend mfsbackup -l 50 -6so /dos/backup.mfs /dev/hdc This assumes you have mounted a writeable fat32 (or ext2) partition as /dos.

To restore the image I recommend mfsrestore -s 127 -zpi /dos/backup.mfs /dev/hdc Again, this assumes you have mounted the partition containing the image.

Always use the -s switch on restore if the drive is greater than 120 Gig.

One way to troubleshoot this is to download an image from the ed2k network and install that. Get the emule client at www.emule-project.net and do a global server search for tivo. All standard definition DirecTiVos are sort of interchangeable EXCEPT for the R10.

PlainBill