1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixes for MFSTools 2.0 swap problems

Discussion in 'TiVo Upgrade Center' started by Robert S, Jul 31, 2002.

  1. Aug 11, 2002 #61 of 609
    kingmiwok

    kingmiwok New Member

    11
    0
    Aug 8, 2002
    Idaho
    Hmmm, something is not working.

    I tried fixes 2 and 4 with (I think) no luck. Tivo is up and running again, but I think my swap file is in the same condition as beforehand and I'll have a lockup in a day or so.

    Note: I am not Linux savvy at all, but I do understand what the commands are supposed to do. I'm vcomfortable with DOS so working from a prompt does not bother me.

    In a nutshell,
    I boot on MadTivo disk and try to run edit_bootparms /dev/hdc -r
    I get "file not found" (or whatever it says exactly)

    If I try to mount a drive from a Dylan boot, I get a variety of responses, none completely positive. It often wants to know the file system type.

    I tried to dd over the 64M swap from the orig Tivo drive and the reply I got back was
    0+0
    0+0
    That seemed wrong.

    I notice during boot that it does not read the partitions and can not identify the file system type. It finds the drives OK though.

    Question: At the beginning of this thread, for repair method 2, is the dd command correct? States going from hdb8 to hdc9. Should be hdb8 to hdc8, yes?

    So if it's possible to guide me a bit... what am I doing wrong? Thanks.
     
  2. Aug 11, 2002 #62 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Yes, well spotted, the swap partition is number 8, of course. You can stare at these things for ages and not see them, you know?

    Assuming your working drive is on hdb and your new drive is on hdc your dd command would be

    dd if=/dev/hdb8 of=/dev/hdc8

    It should say something like 128 records transferred.

    edit_bootparms is in the mad directory on TiVoMad, so you need to do

    /mad/edit_bootparms ...

    (I've fixed this in the top post too).

    mount should give no response if it completes. If it asks for a filesystem type you can take it you're either mounting the wrong partition or a byte-swapped one, Linux can auto-detect FAT, Ext2 and NTFS partitions.

    Thankyou for your comments, hope things start working for you soon.
     
  3. Aug 11, 2002 #63 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    Kingmiwok, that is exactly what happened to me yesterday. I dug out my original TiVo A drive and slammed in my 2 new TiVo drives, expecting to do a 5 minute dump of the old swap onto the new partition, but got the 0+0 in and 0+0 out message just like you did.
    I had all the drives on a second controller card , and used
    dd if=/dev/hde8 of=/dev/hdg8, where I connected the original TiVo disk to the primary master on the second controller, and the new TiVo drive (with the bad 128M swap partition) as the secondary master (and the new TiVo B drive on the secondary slave ).
    I used the MFSTools 2 boot CD, and all drives were recognized on bootup, so I have no idea what the problem was.
    I'm not familiar with Linux, either, so rather than risk doing something bad to my original disk (I have no backup image), I just bailed out, hoping for some help or suggestions online.
    My TiVo started acting wierd on Saturday am, rebooting 6 times in fairly rapid succession. It would work for about 5-20 minutes between reboots, then go again. It seems to have fixed itself, or at least settled down for a bit. Its been up for about 36 hours without any issues.

    Any new info or suggestions appreciated.
    rswift
     
  4. Aug 12, 2002 #64 of 609
    kingmiwok

    kingmiwok New Member

    11
    0
    Aug 8, 2002
    Idaho
    Robert S:
    Thanks for the reply. Based on your comments and what has happened, I have the general feeling that my drives are not being detected correctly when I boot Linux. I'm thinking its not running the commands, mount or dd, etc because it is not seeing the drives in their complete form to begin with.

    For example, cd'ed around a bit and spotted the edit_bootparms in the mad dir. It still blew me off when I tried to run it!

    I'm not sure why, but maybe my motherboard settings are confusing things.
    I think I'll retry with everything dummied down, or do it on another computer where I'm not afraid of messing up the BIOS settings. (I'm always anxious about changing settings on a computer I need for other "real" work.)

    rswift:
    I feel your pain. I'm doing more rapid reboots now after trying to fix it. Nice. I'm backed though, so I feel a fairly safe in trying things without paying too bad of a price.

    My only recommendation it to do what I mentioned above. Maybe try it again with a very simple computer setup. No add-on second controller card, no cards in the slots, the absolute minimum. I think you want HD detection turned off in the BIOS as well. Look at your boot sequence very closely too. Even though my boot was detecting the drives as a physical device, it had lots of comments that indicated that it was not reading the FATS and partitions completely. See if you're getting those too.

    I'll post up any success/failure. I'll try to get to it within the next couple days

    If it does not work for me, I'm going give up the programs I have recorded since the upgrade and redo the whole process. I was interested in learning a little bit more about the inner workings and fixing the swap directly, but it's becoming a drag. My limited linux skill are really beginning to show.
     
  5. Aug 12, 2002 #65 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    thanks, kingmiwok. I probably won't crack the cover again until the weekend rolls around, or at least Thursday. I looked at the boot sequence very carefully and didn't see anything that I thought was troublesome. I used the exact same configuration when I copied and expanded my original TiVo drive that I'm trying to use now to repair swap, so I'd think that I would have run into problems the first time around.
    I'm also curious as to when it's necessary to boot into byteswapped mode. I tried that with the MFSTools CD and got an error and freeze. Had to reset the PC.
    Thanks again for the response.

    rswift
     
  6. Aug 12, 2002 #66 of 609
    jhburke

    jhburke New Member

    5
    0
    Aug 3, 2002
    Darien, IL
    Rswift:

    I had success copying the swap file by booting into byteswapping mode. The easiest way to do this is to boot from the older MFSTools disk (i.e. Kazymir's Boot Disk). Byteswapping mode is broken on the new MFSTools 2.0 disk (you can read the thread at the top of this forum) but it can be done if you type "vmlnodma hdb=bswap hdc=bswap hdd=bswap" at the "Boot:" prompt. The error in the boot disk is that the wrong kernel is invoked if you type "boot: swap" . It loads the dma kernel which doesn't work for byteswapping, which causes the lockup. Read the isolinux.cfg file on the cd if you want to see. I think it will work for you in byteswapping mode.

    John
     
  7. Aug 14, 2002 #67 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    So, being the curious sort, and having an extra 40gb drive, I just finished running a proof of concept.

    Summary: mfsrestore -r 0 works.

    Anyway, here's what I did:

    My TiVo: Philips HDR-212, with TurboNet and 100GB HD (TiVoMad style expansion performed Aug '01).

    Booted with the MFST2 CD (default/dma enabled mode). Backed up my current TiVo drive with:

    mfstools backup -6s -o /mnt/bak/mybackup /dev/hdb

    Shutdown, disconnected good drive, installed test drive.

    Restored with:

    mfstools restore -x -p -s 128 -r 0 /dev/hdb -i /mnt/bak/mybackup

    After completion, I rebooted with the TurboNet 3.0 install CD and installed (for tnlited, primarily).

    Slapped the drive in the TiVo. Booted. Telneted in, ran:

    mkswap /dev/hda8
    swapon -a

    Rebooted. Swap was accepted.

    Ran:

    mfsassert -please

    Waited nervously through the green screen. It didn't green screen loop - once through the green screen, then back to the happy TiVo intro vid and life as usual.

    So MFSTools 2.0 can (apparently, in my case) be made to work completely with a little finagling and not using the defaults.

    Anybody else want to make a test run and either confirm or refute?

    MC
     
  8. Aug 15, 2002 #68 of 609
    Ivor

    Ivor New Member

    13
    0
    Aug 5, 2002
    Middlesex UK
    That's restoring using a minimal backup, right? i.e. no programs saved?

    My attempt at using -r 0 (whilst expanding drives and saving programs) broke even before I had a chance to run mfsassert -please, and didn't recover (see earlier in thread). If I can get hold of a suitable disk I'll try restoring my emergency backup with mfstools restore -x -p -s 128 -r 0 etc. and let you know what happens. It would also be interesting to see how this works on a >140Gb total setup (which requires the larger swap file).
     
  9. Aug 15, 2002 #69 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    Correct. Time (not being patient enough to leave my TiVo down that long for a proof of concept) and space (going from 100gb to 40gb, only having a 2.5gb partition for holding any backup images) were my primary reasons for not attempting the complete backup/restore.

    Besides, that's the best kind of backup to test -r 0 from, the way I figure - it guarantees all MFS partitions are MFSTools 2.0 created.

    Theoretically, it should make no difference - having repaired the swap and gotten it recognized at 128mb, it shouldn't matter what size the overall setup is... But you're absolutely right, it'll be interesting to see if it works regardless.

    MC
     
  10. Aug 15, 2002 #70 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    Any thoughts on a repair solution for a DTiVo? Doing the mkswap after the drive is back in TiVo isn't really a viable option. I've read elsewhere in this post of doing a mkswap while the drive is out of TiVo, then after the drive is returned to TiVo, the swap isn't readable.

    I'm still curious about which copy, backup, restore type commands need to be done in byteswap mode vs. non-byteswap.

    Thanks.
    rs
     
  11. Aug 15, 2002 #71 of 609
    sbourgeo

    sbourgeo Hepcat Daddio

    7,435
    0
    Nov 10, 2000
    New England
    So what's the consensus on new expansions?

    I have an HDR-312 where I had previously replaced the 30G drive with an 80G drive with TiVoMad/mfstools 1.1.

    Based on the Hinsdale directions, I can just put the 80G and my new 160G drive in my PC, boot with the mfstools 2.0 cdrom and run "mfsadd -x" to recognize the new drive.

    According to a post from hinsdale in this thread and in tiger's original mfstools 2.0 announcement, the 64M of swap that I currently have should be sufficient. Is that a fair assumption?

    I just want to make sure I have enough swap to recover from GSOD, if necessary.



    Steve
     
  12. Aug 15, 2002 #72 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    The reason Tiger thinks MFS Tools 2 doesn't need enlarged swap is that MFS Tools 2 uses larger blocks sizes, so mfsfix needs less space to run. However, MFS Tools 2.0 breaks mfsfix anyway, so this is hard to verify.

    You should be OK if you use mfsadd with -r 0, but this hasn't really been verified. This doesn't use the larger block size, so mfsfix should complete, but you'll have to trust that both Hinsdale's and Merle Corey's upgrades are representative of your situation.
     
  13. Aug 15, 2002 #73 of 609
    dobbie1

    dobbie1 Member

    169
    0
    Apr 15, 2002
    Memphis, TN
    I have been following the discussion with much interest, hoping to confirm that the lockups I am receiving on a daily basis now are the result of not having created a swap space when I upgraded my Series2 unit. I don't know if MFS Tools 2 has been updated but I used the version first released. I checked my log files and it does not appear that I have any swap space on the unit. I plan on trying to use the option 2 to fix but since I am not familiar with Linux, but do follow directions very well, are the commands listed for the option 2 fix all I will need execute in order to create a swap? Any comments, suggestions will be appreciated.

    Regards,
    dobbie1
     
  14. Aug 15, 2002 #74 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    First make sure you really do have a swap problem. You should see three lines giving a clear error message about problems activating swap.

    Method 2 should work for you, although I don't think anyone's actually tried it on a Series 2. S2's don't need byteswapping, so you should just boot the MFST2 CD as normal.
     
  15. Aug 15, 2002 #75 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    Not thoroughly, anyway. More datapoints are definitely better.

    Of course, Steve's also looking at a >140GB capacity, so he has a choice between playing guinea pig or playing it safe.

    Specifically, while -r 0 works (at least some of the time), you (Steve) will theoretically need the expanded swap space as well, and will need to do the song and dance to expand it (Robert nailed a good summary of the possible methods in the first message in this thread).

    The guinea pig aspect comes in with not expanding the swap - according to one of Hinsdale's comments somewhere in all of this, the 64MB swap "limitation" may have been resolved in later versions of the TiVo software. If you're the gambling type, you can try not expanding and see what happens.

    Of course, failure would essentially result in loss of whatever you've got on the drive, requiring you to reimage... :D

    Me, I think I'm going to get myself a new drive and play a little more - I'll run another test scenario and see exactly what happens with >140GB capacity, 64MB swap, and that ever so enjoyable mfsassert -please.

    I'll post my results when I've got them, but nobody hold off anything on my account - I haven't even ordered the new drive yet. I'm at least a week or two away from being able to sit down and play again.

    And on a not-unrelated note, does anybody have any idea what's become of Tiger in the last few months?

    MC
     
  16. Aug 15, 2002 #76 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Steve's in a rather sticky situation already. He can't just expand swap because his A drive is already full. He just wants to add a B drive. This should work, there's even a chance it might survive a green screen, but there's no easy way to guarantee it.

    It might be safer to do a pipe transfer saving all recordings (see MFS Tools README, RESTORE section) and using the -xp, -r 0 and -s 128 options to move everything onto the new drive, expanding swap (will need to use one of the repair methods at the top) and then, once the new drive is verified, mfsadd the old drive as the B drive.

    By the way, Merle, what size was your backup image? Did MFS Tools create a new pair of MFS partitions in addition to the original TiVo-created pair?
     
  17. Aug 15, 2002 #77 of 609
    sbourgeo

    sbourgeo Hepcat Daddio

    7,435
    0
    Nov 10, 2000
    New England
    Actually, I thought about doing that...

    If I just run mfsadd to partition the 160G drive, then I really don't have the ability to create another swap partition before (since mfsadd would wipe it out) or after (no space left on new drive) I run it. I wish I had selected 128M swap size when I upgraded the first time, but didn't see the need to at that time... :(

    I may just hold off on adding the 160G for a little while. I have a bunch of recordings that I'd prefer to keep, so that is my top priority at the moment.

    Maybe by then Tiger will get back from vacation or from doing REAL work and can look into this stuff. :)



    Steve
     
  18. Aug 15, 2002 #78 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    The backup image is a stripped down, formerly upgraded, 20 hour image. (The original upgrade was to 100gb - my understanding is that the -s was required in order to destroy the expanded partitions and let everything be done over). When I restored via -x, it created a new pair of MFS partitions to fit the 40gb drive I was dropping back on to.

    If you like, I can re-run the process tonight without -x in the restore and confirm that only a base 20 hour image is restored, and rerun afterwards with mfsadd -x -r 0 /dev/hdb. (Running mfsinfo in between to get the particulars.)

    You're exactly right regarding adding the B drive, and making the new drive into the A being the safest route; I knew I was missing an obvious problem there.

    MC
     
  19. Aug 15, 2002 #79 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    You can do it during - if you do the piped transfer Robert refers to, you'll preserve all your shows, plus create a new swap on the fly, in the process of migrating everything from the 80GB to the 160GB. You can do the expansion at the same time, and even use -p to optimize the layout.

    After that's done (and tested, and the swap fixed), you would run mfsadd to make your 80GB the B drive to your new 160GB A drive.

    It's a slow process, mind you, but it's definitely the safest route, and accomplishes everything you need to do.

    MC
     
  20. Aug 15, 2002 #80 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    That's fine, Merle. I just wanted to be sure you hadn't put a 40Gb image on a 40Gb drive, which would've meant no MFS Tools 2.0-created partitions and rendered your success with mfsfix meaningless.

    The two new partitions mean this was a valid test.

    I suppose showing the same upgrade fails with -r 2 would mean something, but we're pretty sure that's the case. A test on a big drive is the really interesting case, particularly if -r 0 doesn't slow things down too much (keep the -p partition layout changes).

    (Just paranoid, really.)
     

Share This Page