Page 1 of 2 12 LastLast
Results 1 to 15 of 21

Thread: Backup/Restore Hacked Image (Confused)

  1. #1
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    Question Backup/Restore Hacked Image (Confused)

    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/sh...ons#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)
    Last edited by Audiophile; 03-20-2006 at 10:50 AM.

  2. #2
    Join Date
    Jan 2005
    Posts
    126
    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.

  3. #3
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    Question

    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?
    Last edited by Audiophile; 03-19-2006 at 11:37 PM.

  4. #4
    Join Date
    Jan 2002
    Posts
    5,601
    Quote Originally Posted by 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/sh...ons#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.

    Quote Originally Posted by Audiophile
    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
    There's a difference between needing help, and just being plain ole' lazy.

    "You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)

    HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.

  5. #5
    Join Date
    Apr 2003
    Posts
    2,402
    Quote Originally Posted by 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?
    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

  6. #6
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    Question

    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/sh...ad.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?

  7. #7
    Join Date
    Jan 2002
    Posts
    5,601
    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 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
    There's a difference between needing help, and just being plain ole' lazy.

    "You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)

    HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.

  8. #8
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    35

    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.
    Last edited by Audiophile; 03-21-2006 at 12:21 AM.

  9. #9
    Join Date
    Jan 2002
    Posts
    5,601
    OK, this stands out:
    Code:
    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
    There's a difference between needing help, and just being plain ole' lazy.

    "You cannot teach a man anything. You can only help him find it for himself." Galileo Galilei (1564-1642)

    HR20-700 with 2 TB, HR22-100, HR22-100, HR22-100, HR23-100 all running 0x5cd and networked.

  10. #10
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    Question

    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 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. 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 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?
    Last edited by Audiophile; 03-21-2006 at 11:50 AM.

  11. #11
    Join Date
    Apr 2003
    Posts
    2,402
    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

  12. #12
    Join Date
    Jan 2002
    Location
    Chicago Metro Area
    Posts
    56

    35

    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.
    Last edited by Audiophile; 03-21-2006 at 03:24 PM.

  13. #13
    Join Date
    May 2003
    Posts
    245
    Quote Originally Posted by Audiophile
    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.

  14. #14
    Join Date
    May 2003
    Posts
    245
    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.

  15. #15
    Join Date
    Jan 2005
    Location
    Narnia
    Posts
    1,266
    Quote Originally Posted by Audiophile
    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.



    Quote Originally Posted by Audiophile
    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



    Quote Originally Posted by Audiophile
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •