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. nysteelo

    nysteelo New Member

    22
    0
    Apr 8, 2002
    Long Beach, CA
    Damn!.....So much for that bright idea. I guess my hardly used Dtivo is gonna gets 2 new drives and a whole lot of attention right about now.

    Thanks again.
     
  2. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Ok, the commands to determine which partition is the active root partition don't work for me.

    edit_bootparms can't be found so it won't run and I can't mount either of the partitions. I can however look at the disk with pdisk and see the partitions. What I need to know is from that information that I get from pdisk, how do I tell what commands I need to run?

    In other words, each of the partitions has a name. How do those names correspond to the partitions that I'm working with?. I took a guess I was swapping 7 & 8 but I still get the GSOD that reboots over and over and over after just a few seconds.
     
  3. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    The partition labels don't change. The only thing that determines the active the partition is a single byte in the boot block. pdisk can't show this to you.

    At least one of partitions 4 or 7 will be mountable.

    If you just swap the partitions round without running mkswap, then you'll have no swap at all.

    If you run mkswap on your active root partition you'll destroy your TiVo and have to start again from a backup (unless you make a backup file from the partition you're about to overwrite).

    There's not much of a safety net here. Guessing or doing something similar to what the instructions say is not a good idea.
     
  4. tjon1

    tjon1 New Member

    7
    0
    Jul 20, 2003
    San Diego, CA
    Sorry beforehand if my question is a bit unlearned . . . I've spent quite a bit of time reading through this thread, but alas, I only became more confused. This morning I replaced my original Phillips (quantum fireball, 13+gig, 14hr) drive with a 160 maxtor. I used the Hinsdale instructions and MFS Tools 2.0. After completing a backup I typed: mfsbackup -aqo - /dev/hdc | mfsrestore -xpi - /dev/hda. Apparently all went well as when I placed the TIVO back in service it said that I had 148hrs of record time and seems (so far so good) to work just fine. However, reading this thread (and Robert S's original post) it seems I am living on borrowed time and that at some point I am going to have swap file problems. Is this swap file problem still a problem? Because I just did the upgrade, I don't have any new recordings. Can I fix this problem by running the above mentioned commands adding -s with 80 (half the size of the drive)? What would be the precise command? Is the 137gig barrier still a problem (actually I don't care about losing 23gigs, the drive was only 99 bucks)? As if it isn't painfully obvious, I don't have much experience with linux, so feel free to "dumb down" any responses! (and Thanks!)
     
  5. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Just a point of clarification, when trying to determine the inactive root partition in order to do the swap, the inactive root partition is the one that mounts. The one that doesn't is the current swap partition. If they both mount, then the one with the older files is the inactive root partition, right?
     
  6. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    tjon: actually, you're OK at the moment. You have 64Mb of swap plus about 8Mb out of the 16Mb system RAM, which gets you to about 144Gib or about 155Gb before mfsfix falls over.

    There's no way to increase swap without copying your recordings again. See the end of the 160Gb thread in the Underground for a way to use the full capacity of the drive (only worth considering if you recopy).

    Michael: Yes, pretty much. The partition that doesn't mount is empty (literally, all zeroes) and therefore available for conversion into swap. It's your inactive root partition. The other partition is the active root partition and holds your system software.

    If both partitions mount then the inactive root partition is holding the previous version of the system software, which will have older datestamps than the current version.
     
  7. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Wait a minute. Maybe I'm reading your post backward or something. Of the two partitions, only one of them will mount, hda4. The other one comes back with an error that says that it seems to be swap space. I did this procedure last year, although it didn't give me this much trouble then.

    Is 4 or 7 the inactive partition that I should be using?
     
  8. tjon1

    tjon1 New Member

    7
    0
    Jul 20, 2003
    San Diego, CA
    Robert, thanks for the info. I checked out Todd Millier's how-to regarding large disks,( I presume this is what you refer to) but making changes in the kernel that will be overwritten when a new OS version come out unsettles me a bit. I actually don't care much :cool: that I don't have use of the missing 23 gigs (above 137) (btw, my unit reports 164hrs. not the 148 I wrote) and I don't mind recopying the original drive again if it will prevent problems sometime in the future. I presume that this can be done from MFSTOOLS but I am unsure of the exact command(s) that I should use. I am considering removing the drive to perform the live tv buffer upgrade to increase the buffer to an hour, so this would give me extra incentive! Again, thanks.
     
  9. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Michael: Ah, partition 7 is already swap from the last time you did this. That's your inactive root partition (normally it would be blank).

    Look at the partition table (pdisk -l or just read the boot print-out) and check that partition 8 is 128Mb. You might also want to read the TiVo's boot log (I linked to my original post that describes how to do this in the top post). The GSOD isn't infallible, so may be your problem isn't related to swap this time.

    tjon: If you look at the end of the thread some dork managed to copy his patched kernel to the wrong partition and thus booted with the original kernel. The results are less than spectacular (the TiVo just crashes when it tries to access the out-of-range blocks). All you have to do is do the recopy under Knoppix rather than the MFS Tools bootdisk and then dd the kernel across (check out das Monkey's more detailed write-up as well as Todd's).

    As I said, you're OK at the moment because you're below the 150Gb limit. If you wanted to upgrade further you would need more swap, but as long as you stay below 280Gb total you can just do the 'rescue' to recover from a GSOD.

    I don't think the hacks to increase the buffer size work with the current software.
     
  10. philhu

    philhu User Since Day ONE!

    831
    0
    Apr 11, 2001
    Funcity, MA
    pdisk for tivo?

    My tivo does not seem to have this.

    Where can I get a pdisk running on tivo SA svr-2000?

    Thanks
     
  11. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    pdisk (as an x86 binary) is on the TiVo boot CD's and floppies.
     
  12. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Well apparently either my feeble mind is not grasping the concepts listed in these 21 pages and I'm doing everything wrong or it's not a problem with swap. I'm leaning towards the former but for my sake am hopeful that it's the latter. In order to determine which it is, I need specific answers to specific questions. No interpretations of what you think I mean, no references to links in other posts, just straight answers to the questions presented. I know I'm asking to be spoon-fed this, but right now I've been trying to feed myself and I feel like I've got food everywhere except in my mouth. If this is too much to ask, then a straight answer to the last two questions will work. If I had a clue what I was doing in Linux then maybe it wouldn't be so hard, but I don't so it is.

    1. How many times does the TiVo need to reboot after displaying the GSOD for 10 seconds to know that it isn't going to fix itself and I can shut it down and try something else?
    2. I can't get "edit_bootparms hda -r" to work when booting from the MFS Tools CD (downloaded and burned today). If you follow the instructions to the letter in Robert's second post starting with Section A "Booting so we can read the TiVo disk", does it work for everybody else on the planet and I'm just "lucky" or is there truly a problem with the command and/or the CD?
    3. If /dev/hda4 mounts and /dev/hda7 does not mount, which partition is the inactive partition that I should be using in section C?
    4. If /dev/hda4 mounts and has files dating from Jan 2003, and /dev/hda7 does not mount, saying that it thinks hda7 might be swap space, is hda4 or hda7 the partion that I want to use in section C?
    5. Is there a way to make the screen show more than 80 columns so that the output from pdisk is more readable and doesn't wrap around?
    6. What should I be looking for in the pdisk output to verify that I'm setting the right partition? It seemed that both partition 7 & 8 were 128Mb. I'm not looking at it now, so I could be wrong. Neither one will mount however, it thinking thta both may be swap space.
    7. What are the exact steps to look at the boot logs for a version 3 DTiVo while the drive is out of the TiVo and in a PC? The only thing I saw was via enabling backdoors. If I could enable backdoors, it would be working and I wouldn't be asking these questions.
    8. What are the steps to find out exactly what size the swap file is? I'd like to check my other system that is working.

    And lastly,
    9. I have 2 DSR6000s, one originally came with only one drive the other came with two. I still have those original drives, but they are not labeled as to which machine they came out of or if they are drive A or B. I thought I labeled, apparently, I didn't. If I start over and perform the upgrade again using the original disc(s), losing all my recordings, which method is more fool-proof, the single or dual drive option and how do I tell which drives are which, single drive A, dual drive A, or dual drive B so that I can use the appropriate drives with the appropriate method?
    10. Can I run dd using the A & B drives in my DTiVo that is working to the A & B drives of the one that is not and have it work? Is there anything specific to the working set of drives that will not allow me to copy them and put them in the other DTiVo and make it work?

    I really do appreciate the assistance with this. The frustration you may sense is directed inward at myself not outward to anybody else.

    Thanks.
     
  13. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Rebooting after 10 seconds suggests that you have no swap at all (or that the problem does not relate to swap). If partitions 7&8 really are 128Mb then you upgraded with -s 128, so the original swap partition may not have a valid signature on it.

    It takes several minutes for the GSOD to allocate the memory it needs, so if it reboots before 4 minutes have elapsed then it isn't doing anything useful and will never repair the TiVo.

    People do seem to have problems with edit_bootparms, although no-one has explained what the problem is. Anyway, you have correctly identified partition 7 as the one to use for extra swap.

    The data that pdisk displays is a sort of table of contents - it doesn't necessarily indicate what's inside the partitions. The original kernel partition will be titled Kernel 2, but if the swap and kernel partitions are the same size, it doesn't matter.

    To read the logs:

    mkdir /mnt/var
    mount /dev/hda9 /mnt/var

    more /mnt/var/log/messages

    look for messages relating to swap

    umount /mnt/var


    The lone A drive will be 40Gb. The twin A drive will be 30Gb and its B drive will be 15Gb. The sizes should be marked on the drives.
     
  14. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Thank you Robert.

    The drive sizes for the single and dual did match up. Thanks.

    I've included output for some of the commands and a couple of questions at the end.

    The output for edit_bootparms is:

    /# edit_bootparms hda -r
    sh: edit_bootparms: command not found
    /#


    So it seems as though the file just doesn't exist in the path. I don't know how to search for a file in Linux so I'm not much help with this one.

    It looks like partitions 7&8 are both 128Mb. Here's a partial output from pdisk -l

    2: Image Bootstrap 1 4096 @ 75145280 ( 2.0M)
    3: Image Kernel 1 4096 @ 75149376 ( 2.0M)
    4: Ext2 Root 1 262144 @ 75153472 (128.0M)
    5: Image Bootstrap 2 4096 @ 75415616 ( 2.0M)
    6: Image Kernel 2 4096 @ 75419712 ( 2.0M)
    7: Swap Linux swap 262144 @ 75685952 (128.0M)
    8: Ext2 Root 2 262144 @ 75423808 (128.0M)
    9: Ext2 /var 262144 @ 75948096 (128.0M)


    The boot log didn't provide me any useful information, maybe it will for somebody else. The entries related to swap were basically:

    Jul 11 03:30:42 (none) Stats: Swap: 133881856 0 133881856
    Jul 11 03:30:42 (none) Stats: MemTotal: 27922kB
    Jul 11 03:30:42 (none) Stats: MemFree: 14820kB
    Jul 11 03:30:42 (none) Stats: MemShared: 4024kB
    Jul 11 03:30:42 (none) Stats: Buffers: 5080kB
    Jul 11 03:30:42 (none) Stats: Cached: 5124kB
    Jul 11 03:30:42 (none) Stats: SwapTotal: 130744kB
    Jul 11 03:30:42 (none) Stats: SwapFree: 130744kB


    Which makes it look like the swap file is large enough.

    It cycles through the boot process every 6 minutes or so. It will write what look to be normal entries to the log for ~15-20 seconds and then reboot.

    The lines right before and after the reboot are:

    Jul 11 03:03:43 (none) Stats: lo: 0 0 0 0 0 0 0 0 0 0 0
    Jan 1 00:00:32 (none) syslogd 1.3-3: restart
    Jul 11 03:36:47 (none) Stats: == System startup resource statistics ==


    At the very end of the log, the restart line is repeated 6 times one right after another.

    So based on this, do you think it is a problem with the swap? And what do you think my next steps should be? Am I at the point of starting over with the original drives?

    On a related note, and my ignorance of Linux will probably show through, but I don't really understand why the swap size can't be fixed, if the partition is 128Mb and you need 127Mb, why can't we just create a valid signature and have it work?

    Thanks
     
  15. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    It does look like you have 128Mb of swap. Therefore, whatever the reason mfsfix is crashing, it's not running out of memory.

    You appear to have misunderstood your situation. You restored with -s 128 and therefore got a corrupted swap signature on partition 8. You should have just run mkswap on that partition as described in the first post.

    The rescue in the third post is intended for people who have 64Mb of working swap, but need more to recover from a GSOD.

    Anyway, it looks like that's irrelevent now - if you can't figure out what's wrong, you'll have to restore from a backup.

    Have you run diagnostics on the disks?
     
  16. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    It doesn't surprise me that I'm confused.

    I didn't think that if you used the -s 128 option that it could be fixed easily. Everything I've read states that it can't be fixed without lots of work like hacking the kernel.

    I was getting reboots where it would be up for ~5 minutes and then reboot. I ran the Maxtor utilities on the drives, which showed one to be bad. I got the replacement from Maxtor and used dd to image the drive over to the new one. There were a few bad sectors, so when I went to boot up, I got the GSOD and have been trying since to get past it.

    Unless you've got some ideas on what to look for, I guess I'm starting over.
     
  17. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Yeah, that /was/ my bright idea. Shame.

    You do need to run a different kernel to get 128Mb of swap, but if you run mkswap on a 128Mb kernel it gives you 127.3Mb. Unfortunately Tiger didn't notice this problem when he wrote MFS Tools, so although it tries to give you 128Mb or more of swap, it can only create a valid swap signature for up to 127Mb.
     
  18. Michael248363

    Michael248363 New Member

    69
    0
    Jul 22, 2002
    Salt Lake...
    Thanks. You're *dim* ideas are much better than my *bright* ones.
     
  19. tjon1

    tjon1 New Member

    7
    0
    Jul 20, 2003
    San Diego, CA
    Robert S.

    Just wanted to say thanks for the information (re 160gig upgrade). I gather from your remarks that as long as I don't let the disk fill up I shouldn't worry about running into swap file problems. I don't tend to watch shows over and over again so it shouldn't be a problem. Again, thanks!
     
  20. Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    I gather from your remarks that as long as I don't let the disk fill up I shouldn't worry about running into swap
    file problems.


    I think what I said was as long as you don't fill the whole drive with recording partitions. That is, you do the upgrade the old way for 137Gb. Doing the upgrade with an LBA-48 kernel would put you over the 155Gb threshold where you need more than the original 64Mb of swap.

    However, you'll presumably use mfsrestore with -s 127 to get 127Mb of swap, which is enough for about 280Gb, so you'd be fine as long as you didn't add more than 120Gb to your 160.

    The important factor is the size of the partitions. How many recordings are inside them is irrelevent as mfsfix will crash before discovering how full they are.
     

Share This Page