Fixes for MFSTools 2.0 swap problems [Text View] - Page 2

Jorossian

10-12-2002, 06:57 PM

Great stuff Rob. I've copied your updated instructions for future reference. So all this crap has been caused because of using "128" instead of "127". Glad to see my Hinsdale's directions are already updated and free of that problem.

I feel a lot better about using Tiger's MFS Tools 2.0 to do this now. Unfirtunately my 120 Gig hard drive still hasn't arrived. I may have to put this off until next weekend.

Here's a new question.

If I simply move the image of my A drive to the new larger drive + expand it and keep the original A out of the unit for a while until I'm sure everything's "kosher"......... Will I lose more usable space when I eventually add the original 40 gig A drive (now B) to the new 120 A ? And does the addition of the original A count as another "upgrade" essentially putting my overall TiVo setup at 2 upgrades with possibly one more possible upgrade left?

I guess what I'm getting at is, am I better off putting in 2 new hard drives all at once NOW rather than one now and one in another month or so?

Tiger

10-13-2002, 03:03 AM

There is no difference as to the number of upgrades of putting a drive in now or later. The number of upgrades counts each drive upgraded, so in both cases larger A + new B (Now or later) is 2 upgrades. Also the limit isn't necessarily 3, that is just worst case scenerio. You can have a total of 6 MFS sets. Standalone series 1 has 1 set in most case. Dual drive combo has 3. Single drive combo and series 2 standalone have 2. So larger A and new B gives you a chance to upgrade both drives one more time. (Though you have to do both at the same time if you want to use both upgrades, as it will need to shuffle partitions around)

Jorossian

10-13-2002, 10:22 AM

Appreciate that Tiger. Thanks for the great software.

comfysofa

10-13-2002, 03:21 PM

hmmmm - well because nothing happened on the first night i tried i took the discs and stretched the filesystem over the new disc which took me to 314 hours........so - assuming i still have the old swap size - (gotta wait for the wife to finish with the tivo) ill check the logs - think you need a reboot first.......can the adjustments be made from a telnet session (without the need to take it apart).......

Robert S

10-13-2002, 03:27 PM

There's no room to add more swap. It's best to do it at the mfsrestore stage.

rdangel

10-28-2002, 10:11 AM

Robert S:
I had a previously upgraded Phillips 20 hr. Added an 80 GB B drive using blesstivo and have been fine for a while. Recently decide to change out the 20 GB A drive for a 120GB A drive.

Did the upgrade,everything is fine. Have been using the tivo for a few days now. Read over your manually adding swap file thread and have a question. Will this creating procdure damage the married drives at all? Will I just be able to add/create/expand the swap without losing my recordings, breaking the marrying etc?

I have been noticing that the a drive locks and I keep having to run qunlock.

Any help would be appreciated.
Thanks

Robert S

10-28-2002, 10:32 AM

The procedure for adding extra swap manually has been tested and seems to be working well for people. You need to do it between dd'ing the drive on to the new one and using mfsadd to expand the image. If you've already expanded you can't expand your swap and will have to use the 'rescue' procedure if your TiVo ever green screens.

The 'marriage' is transferred when you use dd to copy the drive. changing the swap partitions around doesn't affect the MFS partitions where your recordings are. mfsadd adds extra space without damaging the recordings already on the disks.

TiVo will relock the drive it you boot it. qunlock is only a 'permanent' unlock in the sense that it won't relock in a PC (the distinction is actually against dlgchk.exe which only unlocks the drive until you turn the power off).

rjbutler

11-11-2002, 01:37 PM

I upgraded my DirecTivo B drive to a 160GB Maxtor some time ago and ended up with a 64M swap. Lately, I've noticed very slow responses, occassional audio drops during playback and sometimes video dropouts on recordings on days there should not be rain fade problems.

Is it likely the small swap partition is the cause of these problems or is theresomething more serious wrong?

I've scanned through this topic and I *think* I can increase the swap to 128M using option #3 in the first message:

3. Use copy of mkswap on tools CD

Boot a TiVo boot CD (but not the MFS Tools 2.0 CD) and do

/sbin/mkswap -v0 /dev/hdc8

Is my interpretation correct? Will this effect my recordings?

Thanks

Robert S

11-11-2002, 06:43 PM

Wrong on both counts, I'm afraid. The increased swap is only relevent when your TiVo undergoes a 'green screen' file system corruption error. You need relatively little swap at other times - probably less than 20Mb would be fine for normal operations. A DTiVo might even be OK with no swap at all.

You can't increase swap because you've got no where to put it - the 4 procedures in the first post assume you've got a 128MB partition that hasn't been initialised by MFS Tools 2.0 (which happens if you upgrade with -s 128 as suggested by the MFS Tools 2.0 documentation).

You will want to take note of the next post which describes how to temporarily increase swap to help your TiVo recover from a green screen of death.

Your playback problems are probably due to a failing disk. You might want to run PowerMax on your drives to see if it can identify which one has the problem.

rjbutler

11-12-2002, 01:00 AM

I used MFS Tools 2.0 soon after it came out, before the swap issue was discovered. I don't recall if I used -s 128, I followed the Hinsdale instructions for a 2 drive DTivo, upgrading the B drive only.

The logfile reports a 64M partition.

I guess I'll try PowerMax this weekend to see if I've got a bad drive.

Thanks for the info.

boobili

11-12-2002, 11:12 AM

Originally posted by Robert S
Wrong on both counts, I'm afraid. The increased swap is only relevent when your TiVo undergoes a 'green screen' file system corruption error. You need relatively little swap at other times - probably less than 20Mb would be fine for normal operations. A DTiVo might even be OK with no swap at all.

You can't increase swap because you've got no where to put it - the 4 procedures in the first post assume you've got a 128MB partition that hasn't been initialised by MFS Tools 2.0 (which happens if you upgrade with -s 128 as suggested by the MFS Tools 2.0 documentation).

You will want to take note of the next post which describes how to temporarily increase swap to help your TiVo recover from a green screen of death.

Your playback problems are probably due to a failing disk. You might want to run PowerMax on your drives to see if it can identify which one has the problem.

Hi Robert. I might have missed it reading thru this long post. If I had, please forgive me. In your initial post, you described how to recover from the GSD, using a working shell on the TIVO. I am in such a situation. I have the GSD that has not resolved itself for several days, yet I have a working telnet. Can you go into more detail on how to fix the GSD problem under these conditions? Thank you. B

Robert S

11-13-2002, 07:44 AM

The fix applies only if the GSOD is running out of swap - if it reboots a few seconds after going to green, then the fix will help. If the green screen is staying up, then you already have plenty of swap.

Search back through my posts yesterday and you'll see a discussion with someone else trying to do the rescue on the TiVo. In my opinion, it would be much easier to follow the rescue plan in the third post of this thread, even though that does mean opening your TiVo and PC.

jeffster

11-14-2002, 11:37 PM

Robert,

Which of the (#2 & 3) options mentioned at the top of the thread for rescuing DTivos is the best?

I have a SAT-T60 that was just upgraded to 220GB, and got it home to see the green-screen reboot loop.

I'm not the one doing this (I haven't used unix since grad school), so I'll need to point the directions out to someone else who's not going to scan the whole thread.

TIA,

Robert S

11-15-2002, 08:29 AM

The four options in the first post are for repairing TiVoes with no swap (if you actually read the post, this will become clear to you). The rescue is in the third post, and there really is only one way of doing it.

jeffster

11-15-2002, 12:50 PM

Okay, my DTive SAT-T60 with a 100+120 has been in mfsfix (green screen) recovery mode for about 3 hours now.

How long should I expect it to run?

(The green screen came up the minute I added the 120, so only the 100 actually had any video on it.)

jeffster

11-15-2002, 01:13 PM

I had only to ask. Now it's done.

Odd thing -- I lost 40 hours of programming (now just 205 available, said 240 before the mfsfix run).

bonurn

11-20-2002, 11:59 AM

[QUOTE]Originally posted by gigageek
Boy, I wish I had your instructions when [B]I started on this. ;)

Well, I did have these instructions, and they were fantastic. Thanks again to Robert S and gigageek for taking the time to create them.

I upgraded my SAT-T60 with two 100 GB drives. (I did this back in September.) I woke up one Sunday morning to find the infinite GSOD/Powering Up loop. I immediately jumped on the message boards and noticed some discussion about the 3.1 upgrade, specifically Deano's post. I thought that perhaps this is what caused the problem since there was no power outage overnight. Of course, there was no way to check my software version because of the GSOD.

After some searching, I came upon this fix. When I performed my upgrade, it was after the discovery of the 128 problem, so I didn't think that was it, but I figured since I was in the infinite loop, I'd give these instructions a shot. Well, so far so good. My system is back and humming. My software version is still 2.5.2, so the 3.1 upgrade sitll lurks.

Some questions remain (more informational and rhetorical than anything else):

1) There was a Service Data Download the night of the failure. I wonder if this is the 3.1 download that hosed the system. Or could it be something else in that download?

2) gigageek : why in your instructions did you delete the partitions then recreate them instead of just renumbering them? Just wondering.

Thanks again!

-bonurn

Eccles

12-01-2002, 04:01 AM

Originally posted by Robert S
TiVo disks can not be read by a PC because the bytes are written in a different order to that expected by the PC's processor. TiVo boot disks are patched to boot in a 'byteswapped' mode that allows the TiVo data to be read.

Most people these days seem to be using the MFS Tools 2.0 CD. MFS Tools 2.0 has internal support for byteswapping so that CD boots in non-byteswapped mode by default. It offers you the option to boot byteswapped, but this doesn't work. To boot the MFS Tools 2.0 CD byteswapped at the 'boot:' prompt you must type

vmlnodma hda=bswap

If you can't get this to work, try Kazymyr's boot CD or TiVoMad's boot CD. If use a different boot disk, hda will be left unswapped. Use one of the other connectors and adjust the commands below accordingly. (We don't currently know how to do this from a floppy, one of the tools we need is only on the CDs).

How can I (or can I at all) get the MFS Tools 2.0 boot floppy to boot in byteswapped mode? I've spent the past couple of hours trying all manner of convolutions, because the lame old PC I'm using for the task cannot boot from CD and when I boot from the floppy I don't (appear to) get a chance to specify any parameters; there's no boot: prompt, it just starts loading.

From what I read here, this is not a barrier to performing a copy&expand, so I'm going to go ahead and get that going before I go to bed, but it would be nice to be able to make a backup of the old A drive at some point as well.

Is there a non-byteswapped 2.0 floppy image available anywhere?

stormsweeper

12-01-2002, 04:39 AM

You can use MFS Tools completely in non-byteswapped mode. You only need to use byteswapping if you're modifying files (say to set up a bash terminal) on a Series 1 machine.

Eccles

12-01-2002, 05:00 AM

Originally posted by stormsweeper
You can use MFS Tools completely in non-byteswapped mode. You only need to use byteswapping if you're modifying files (say to set up a bash terminal) on a Series 1 machine.

Yeah, I guess I was doing things wrong. I thought I only needed to backup my A drive since that was the only one I was expanding, but in retrospect I see I needed to mounts both A and B to create the backup. My bad. Thanks.

Robert S

12-01-2002, 07:47 AM

You can't make the the MFS Tools 2.0 floppy boot byteswapping, but then you don't need to because MFS Tools has internal byteswapping.

If you need to boot byteswapping for some other reason, just use a Dylan or TiVoMad floppy, they have all the tools other than MFS Tools.

raiders

12-04-2002, 12:26 PM

got a gsod reboot loop on a series 1 directivo with a 200MB configuration of 120mb maxtor disk a and 80 mb maxtor disk b

Followed Robert's instructions from the 3rd thread and the directivo is now back up. Is there a specific place in the logs to look to determine what caused the gsod. Ran the maxtor disk utilites and the drives are ok.

Is there a way to increase the 64mb swap to 127mb using the existing disks without losing recordings so that a future gsod can attempt recovery automatically?

Thanks to all who contributed to this thread and helped with the instructions on recovering from gsod

gigageek

12-09-2002, 07:32 PM

raiders: No, there is no way to increase the 64mb swap to 127mb using the existing disks without losing recordings. There is no unused space on the disks, so they would have to be repartitioned (thus blasting all recordings) to change the size of the swap partitions after the fact.

bonurn: The reason I deleted/recreated my partitions was because I had renamed them after I renumbered them (in retrospect, this was ENTIRELY unnecessary); deleting/recreating the partitions was less work to get back to where I started than was renumbering & renaming them (although probably not much less work). If you just renumbered the partitions to do the GSOD fix, just renumber them to put them back the way they were.

acrobidoux

12-27-2002, 02:54 PM

Hi Everyone,

I am looking to buy a Hughes DirecTivo 2 system and adding a large drive to it, replacing the existing single drive.

My company is going to be purchasing a Logicube Solitaire Turbo Hard Drive duplicator for me to use at work. Has anyone ever used a drive duplictor with the Tivo drives? This unit will make an exact copy bit by bit of any OS, therefore I will have the required swap file that everyone is talking about (although it will be 64MB). I did not read through this entire post, but did read that Hinsdale thinks the 64MB will be enough due to the new versions of the Tivo software. What are your thoughts on this?

Also, I am considering the Western Digital 1200JB (120 GB) hard drive that has an 8MB cache (all other drives use 2MB) and 7200 RPM Speed. This drive is fairly quiet as I have installed several in PC's at work. Has anyone used this drive? Will I see a performance gain using this drive with the Tivo? In PC land, these drives perform better because of the larger cache.

Thank You

And Sorry if I am asking a question that has been discussed before!

Andrew

gigageek

12-29-2002, 07:34 PM

acrobidoux,

I don't know about that particular drive duplicator, but my guess is that it will hose things up unless you're duplicating your current TiVo drive onto another identical drive. (And what, exactly, might be the point of that?) After it faithfully copies every bit of the old drive (including partition info), what do you suppose it might put in the unused space on a larger drive? My recommendation: just use MFSTools like everyone else.

As for the WD120JB, you're wasting your money on the 8MB buffer. The original DTiVo drives (which are capable of recording 2 shows while watching a third, previously-recorded, show) are only ATA33 with 512kB buffers. The larger buffer is good for PC performance, but useless for the TiVo application (continuous streaming of data, as opposed to random file access).

I've got a WD120BB (2MB buffer) in my SA TiVo, and it works fine. It's a little bit louder than the Seagate Barracuda ATA IV (ST380021A) in my DTiVo, but Seagate didn't make a 120GB drive earlier this summer when I bought my drives. As always, YMMV.

Robert S

12-29-2002, 08:20 PM

Why does everyone want to use some strange new tool for TiVo upgrading when there are well documented tools and procedures that work much better? I suppose I should give you some credit for not asking if you could use Norton Ghost, though :)

This machine will make an exact copy of your TiVo drive on to any drive of equal or greater size. The drive will work in your TiVo, but will appear to be exactly the same size until you use MFS Tools to expand it.

If you don't expand swap, you can put no more than 180Gb of disk space in your TiVo without breaking the mfsfix filesystem repair utility.

There are circumstances where cloning a disk this way is a good idea, although you can do the same thing with dd in a PC if you don't happen to have a drive duplicator handy.

If the TiVo is new, it would be a better idea to do an MFS Tools backup and restore to transfer the image to the new drive. (You only need to clone the drive if you want to keep your recordings). This will be much faster and allow you to expand your swap painlessly.

Once your new drive is full (ie, you're sure it's OK), you can use MFS Tools 2.0's mfsadd function to add the original A drive as a B drive if you still want more space.

acrobidoux

12-30-2002, 07:33 AM

Thanks Robert S,

I was wondering if you would still need to expand the drives using the tools.

The tools sound like the best and only route to take, although once I get everything on a new 120GB drive I might use the duplicator machine to keep a backup on hand. This will allow me to bypass taking the drive out of the Tivo and putting it in a PC when/if the Tivo crashes.

Norton Ghost:) :) :) :) :) is a joke!

Thanks Guys,

Andrew

mhubbard44

01-03-2003, 01:13 AM

I've been following this thread hoping to read about a way to upgrade/save a dead A drive without losing all my recordings. I've been reading these threads about swapping file--is there any chance I can use a working B drive to allow Tivo to boot and possibly repair its self with a new swapping file?

Background: Sony Sat-T60, A drive: stock Quantum Fireball 40GB, B drive self upgraded Maxtor 4G120J6 (120GB). The upgrade went fine almost a year ago. One morning recently I turned the TV on and the unit said powering on. It's been stuck there ever since. I wonder if a software upgrade initiated the failure.

Anyway I've run the Maxtor drive testing utility with both Tivo drives as the only drives connected to the PC and the Tivo A drive is not even recognized as a hard drive to run the utility against. The Tivo B ran through the basic and the advanced test with flying colors. Is there any chance anything but an a complete disk failure would cause the disk to not be recognized as a drive?

Also is there a way to save or restore the A drive with the bootable Tivo CD and some of the linux based tools? If not does anyone know if this PTVupgrade.com place can really save your recordings with their get well kit? Are there any log files on the Tivo B drive that would be helpful in diagnosing the problem? If I restore from my pre-upgrade backup to Tivo drive A do I lose all the programs on the second drive even though its already been blessed? Basically is there is anyway to save any of your recordings when you have a failed Tivo A drive?

FYI I work in the PC industry so anyone responding please give me the technical answer no need to dumb it down for me. If someone can point me in the right direction I'll do whatever possible to save my recordings. I have the entire second week of Spielberg's taken on my Tivo and I will do anything to get my movies and stuff back.

Thanks in advance

gigageek

01-06-2003, 07:14 PM

Dude, I think you are SO screwed. :eek: :mad: :eek:

It sounds like your A-drive has gone Tango Uniform on you; if so, there is no way to get any of your recordings off. To draw a PC analogy, the OS and FAT are on the (dead) A-drive. Two-drive TiVo units are much like a logical drive that consists of two physical drives, and you lose everything if either drive dies.

You can restore your backup onto your current B-drive (should give you ~100 hours), or buy another 120GB drive and have a really huge TiVo. This won't get your recordings back, but it will get your thumbs & season passes back to where they were when you made the backup.

You did make a backup when you upgraded, right?

douglasec

01-21-2003, 02:57 AM

I have a Series2 80 hour that I'm trying to expand with (hopefully) a new 120Gb and new 100Gb drive. I have the bracket from 9thtee and the Y adapter and ATA 100 IDE cable BUT have a question about possibly ambiguous instructions in the Hinsdale FAQ. In Config #3 (single to new A&B drives), saving all recordings, it says:

"NOTE: Remove the "-s 127" from the following command lines if backing up/restoring a Series 2 80hr image (does not function with increased swap)"

The command line is given in the FAQ as:
mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi - /dev/hda /dev/hdb

QUESTION (finally!)...does this mean remove the "-s 127" (which increases swap file size) ONLY IF RESTORING TO ORIGINAL (OR ANOTHER) 80Gb DRIVE BECAUSE IT"LL RUN OUT OF SPACE FOR THE SWAP FILE? In other words, if I'm expanding to two new LARGER drives, shouldn't I also leave in the "-s 127" command to expand the swap file- is this an ambiguity which should perhaps be reworded in the FAQ? Is there any way to ask a senior forum member what the appropriate command is (and perhaps why?) I've also seen reports that the Series2 units with extra RAM *might* not need the expanded swap to complete recovery from the GSOD (even with 220Gb?) and wondered if this might not be a reason why you WOULDN'T want to expand the swap - anyway, I'm "stuck outside of Mobile with the Ambiguity Blues again", as little Bobby Zimmerman would say...I'd like to do this once and do it right (especially saving all the recordings and the time involved with that route)...thanks for all the superior brainpower!

Websteria

01-24-2003, 02:52 PM

because I'm thinking of doing the same thing. I'm going to take my existing 80mb drive and copy it to a new 120. In the FAQ it states:

Note: Remove the -s 127 from the following command line if restoring image to the original TiVo A drive or if restoring a Series 2 80 hr image (reported that this unit may not create a working image with increased swap)

Is this accurate?

douglasec

01-24-2003, 07:03 PM

I got tired of waiting and had more time to ponder, and decided to go ahead with the -s 127. It WORKED! It took over 12 hours to transfer all the 75Gb of programs, but it just now booted right up with the new time (250 hours!) and similar noise and heat. I think my guess about not having room to increase the swap if restoring to the same drive was correct in retrospect, but bigger drives should have no problem. Even the lates FAQ now says "MAY" not work, where the earlier one said "WILL' not work if restoring an 80 hour Series2 image. Some 80s are a "little" bigger depending on brand and model, so I guess it's conceivable the extra swap might work with a new "80Gb" drive that had some room to spare compared to the 80Gb WD Performer it replaced, but a 100 or 120Gb seems like a sure thing from my experience. Go for it!

Websteria

01-25-2003, 09:46 AM

Thanks! Post back in a few weeks and let me know if you've experienced any strangenesses with using the -s 127 flag. I'm planning on waiting at least until my warantee period is up (March, sniff snuff) to crack the box... although, if something was going to break, would you think it'd be the hard drive? Hmm...

Thanks.
Jeff

douglasec

01-25-2003, 01:21 PM

Websteria - It's more complex but you should consider using BOTH drives - the only problem is you are asking for trouble if you just mfsadd or blesstivo to add the second drive if you DON"T add the additional swap .... though recent posts here suggest if you know the GSOD rescue routine in the first few posts of this thread is not such a big deal since chances of it happening to you are very small, so why agonize over it (like I did, of course) if it's not a widespread problem. You could just blessthe 120Gb, add it as the second drive and "voila!" - 200Gb at yourcommand!

Websteria

01-27-2003, 10:03 AM

I might do that, but I was going to wait on purchasing the mounting bracket from 9thtee.com until I was ready for my second drive... perhaps I should do it now.

So are you saying I'd need to expand the swap on my existing 80, or add the swap on my new secondary 120 then?

Thanks.
Jeff

douglasec

01-27-2003, 10:56 AM

Originally posted by Websteria
I might do that, but I was going to wait on purchasing the mounting bracket from 9thtee.com until I was ready for my second drive... perhaps I should do it now.

So are you saying I'd need to expand the swap on my existing 80, or add the swap on my new secondary 120 then?

Thanks.
Jeff

Possibly neither, since some higher-level posters on this thread are suggesting that it's a tempest in a teapot, since the GSOD recovery info at the top of this thread could be used in the very slim eventuality that this happens to you. Someone suggested just taping a note with the info inside your case in case it ever happened to you and you forgot what to do. If you buy into that, get the bracket and just ADD the new 120 (BlessTiVo or similar while hooked up to a PC for a minute), plug it in on the new bracket and you're done! Quick, relatively painless and mostly a question of whether you can sleep soundly at night knowing you "only" have 64Mb of swap space, which for maybe 98% of owners will be all you ever need.

Websteria

01-28-2003, 09:32 AM

If I do add the 120, is it going to definitely cause problems if I do the -s 127 switch to add the swap space, or not. :-) It sounds like it's not definite that it won't cause problems if I don't... the FAQ isn't really clear on this issue.

Edit: I did read something in one of the higher posts about the TiVo needing larger swap space if you're going to expand beyond 180 gb (which I will eventually), so I think I'm going to go with copying everything onto the new 120 and then eventually buying another 120 (or 160 *grin*) and installing that one. That way I can keep my existing 80 as a secondary backup to the one MFStools makes in case something goes awry.

Thanks for all your help! I ordered the mounting bracket yesterday.

Scot

01-29-2003, 08:08 PM

Last October I upgraded a Philips DSR6000 with one Western Digital 120 Gb drive on A, then later installed a Maxtor 120 Gb drive for B. In each case I followed Hinsdale's procedures for upgrading a single drive, but unfortunately I did not catch the part about increasing the swap space, and left it at the default 64 Mb. That error came back to bite me a couple of weeks ago when the unit started to spontaneously reboot. The reboots happen after viewing about five minutes of recorded program, or in trying to record. I should note that both drives are nearly full, within a few hours I'd guess, of programs that I have set to not delete unless I do it myself (green ball). Thinking that deleting some of the shows might help whatever the problem was, I killed about twenty hours of programming, but it was no help.

I thought it might be a problem with the A drive (it was making a clunking sound when the spontaneous reboot started), I dd'ed the contents of the A drive onto a spare 120 Gb Samsung, then used mfsadd -x /dev/hdc /dev/hdb to marry the new A to the old B. The spontaneous rebooting continued and eventually the thing went into the GSOD loop, so I applied the trick of temporarily using the unused root partition as swap, and got the thing going again, but the spontaneous reboots continued.

While it was up, I started deleting more shows, this time starting with the most recently recorded. The time between spontaneous reboots seemed to increase as I did this, but that's not conclusive. Anyway I didn't get very far with that approach because the thing went into the GSOD loop again, and the partition swap trick doesn't seem to be working (after about three hours, anyway). I'm thinking I'll let it go all night to see if it heals itself, but I'm really hoping that I've missed something else that will get the thing working again without trashing the recorded shows.

I'm pretty sure it's a data/software problem, as reinstalling the original drives results in a rock stable TiVo again. And I've run the manufacturers diagnostics on the upgrade Samsung and Maxtor drives, and both tested out fine.

At this point it looks like I'll have to repeat the upgrade process, this time increasing the size of the swap partition. But I'm leary of doing it, as there seems to be something else going on that's causing the spontaneous reboot, and I'd hate to load it up with programming again only to end up in the same place. Can one of the gurus out there think of anything about the retention settings I used, perhaps interacting with the full state of the drives, that could have kicked this off? It's at 3.1.0.

Thanks in advance for any ideas...

Scot

douglasec

01-30-2003, 02:48 PM

Scot - sorry to hear about your rebooting - I know Mac drives (as an example I know well) start getting squireelly when you leave less than about 10% free space on a drive because of increased danger of cross-linking files in little fragmented sectors left over from previous erasures; seems to both slow and mostly confuse the OS. Dunno if TiVo-nix has the same problem, but your deletions sound like a reasonable attempt. Maybe you could see on a PC the ACTUAL size in bytes of your 120s, and if the currently unused one has 64mb additional space to create the larger partition for the 128Mb swap file while transferring from the existing 120 (out of luck if it's the other way around, however)...how's your temperature? Some 120s are really toasty (especially two of them) and I know drive-related heat and/or weak power supply causes lots of reboots on Windows machines. You could upgrade to a new 160 "A" drive (adding the swap at that time) but perhaps you've already bought enough drives for this year, especially if you have a motherboard or power problem! I'm actually rather a TiVo newbie, though I've worked with Macs and Wintels for donkey's years, so get a second (third, fourth) opinion from a TiVo God first; YMMV.

Michael248363

02-05-2003, 11:41 AM

I've been overloaded with information and options! Some of which seemed to be conflicting at times. I've read through this thread and I'm only a little bit closer to knowing what I need to do, but nowhere near close enough to be able to actually do it. I guess what I need are step-by-step instructions on what I need to do based on the units that I have. I hate asking to be spoon-fed this, but I have no experience with Linux beyond what I did for the upgrade. I've used PCs for years so working w/ hardware and command prompts don't scare me.

I've got two Phillips DSR6000 DTivo units. Both were upgraded back in July '02 using Hinsdale's instructions and MFSTools 2.0. Each unit has dual 160Gb drives (259hrs each). One of the units is currently in GSoD reboot hell. The other is operating fine. I have done no hacks, backdoors, shell access, TivoWeb, etc. to either of the machines other than the HD upgrade and S-P-S-9-S to get the time to display.

I would really prefer not to lose my season passes and everything that I've recorded. So that said, what do I need to do to fix the one that is in GsoD reboot hell and what do I need to do for the one that is currently running normally?

Thanks for the help.

Robert S

02-05-2003, 01:39 PM

You should be able to fix the reboot loop by following the 'rescue' maneuver in the third post of this thread. I think it's sufficiently 'spoon-fed', but do let me know if you need clarification.

Do you remember what options you used for the upgrade? I assume that you didn't do -s 127 because of the reboot loop. Is it possible you did -s 128? See the first post in this thread (and Cpen's post on the first page) for instructions on how to check this.

If you did -s 128 then instead of the rescue maneuver you should manually initialise your swap as described in the first post. You can/should do this to both your TiVoes.

On the other hand, if you didn't use -s at all, then you can't permanently increase your swap, but the rescue maneuver should allow your TiVoes to recover from a green screen if it happens again.

Note that the TiVo can not take a software upgrade while it's in the 'rescue' configuration (because we're using the space required for the upgrade for swap). However, as DTiVoes do not seem to be due for a software update any time soon you can regard backing out of the rescue as non-urgent.

Michael248363

02-05-2003, 06:39 PM

Thanks Robert. It probably is pretty straight-forward once you know which instructions to follow. :D

I don't remember what the options were that I used when I did the upgrade. It could have been "-s 127", "-s 128", or nothing at all, I don't remember.

A couple of questions for clarification before I start and remove my ability to get on-line and ask questions. I apologize in advance for the quantity and of questions and their probable obvious answers. I feel a little embarassed that what seems like it should be a rather straight-forward task is causing me, and therefore you, so much grief. :o

1. Both of my DTiVoes have A & B drives that are 160Gb each. Do I need to do something to both drives or only to drive A? In post #3 you talk about upgrading twin-drive TiVoes, so I got a little confused because I don't still use the original A drive. I don't think that section applies to me, but wanted to make sure.

2. Is there a way to validate, once the drive is connected, that you are working with drive A and not drive B. It seems like when I did the upgrade, I followed the instructions but the drives weren't cabled or jumpered the way I thought they would be.

3. For my DTiVo that is in the GSoD loop, I have to go through the steps to renumber the partitions in the third post of this thread. For my DTiVo that is working normal, I don't because this process just allows fsck to run. Correct?

4. After I find out which partition is the root partition do I still need to mount the drive or is that portion only if "edit_bootparms" doesn't work?

5. In step F, where I restore the original partition numbers, I use the exact same commands based on what the original inactive partition was. If the at the beginning the inactive partition was 4, then in step F, I would type:
r 8 4
r 5 9
The order or anything else doesn't change since I have renumbered partitions, correct?

So after putting the rebooting DTiVo back together and letting it fix itself (hopefully it will), I should now have two working DTiVoes. Which leads me to the steps to prevent this from happening in the future that I need to do to both machines so that I don't have to go through this again.

6. Does what I do to fix the "future" problem depend on what "-s" parameter I used? If so, which steps do I use based on what I find out from the logs? Is there one set of instructions that I can use regardless that will increase the size of the swap file and still maintain my settings & recordings?

7. How do I tell whether I used "-s 128" or didn't use "-s" at all. From what I can tell, after I enable backdoors and access the log, if I used "-s 128", I should get the error messages that CPen stated saying it was "unable to find swap-space signature" because the swap file was never created. If I didn't use "-s", I don't know what I should see. If I used "-s 127", I shouldn't be reboot looping so that's not really an option.

Thank you very much for your help.

lemketron

02-05-2003, 07:22 PM

Originally posted by Michael248363
7. How do I tell whether I used "-s 128" or didn't use "-s" at all. From what I can tell, after I enable backdoors and access the log, if I used "-s 128", I should get the error messages that CPen stated saying it was "unable to find swap-space signature" because the swap file was never created.
That sounds correct. I have seen this myself as I did several upgrades last summer with "-s 128" (before it was known that this was bad).

If I didn't use "-s", I don't know what I should see. If I used "-s 127", I shouldn't be reboot looping so that's not really an option.

That sounds correct as well. If you did "-s 127" presumably everything would be fine. If you didn't use "-s" then I believe the upgrade process would have left the original 64MB swap partition. This (as noted) can cause problems down the road since fsck (or whatever the repair utility is that TiVo may one day run?) can't successfully run on two 160GB drives with only 64MB of swap space.

How can you tell? You'll probably have to dump the partition map and see if you can identify the swap partition. I don't recall which partition it's usually on, but if you hook up the boot drive to your PC and boot the MFSTools CD, you may be able to see the partition information displayed as the CD boots -- or maybe someone else can followup and tell you specifically how to tell whether your swap is 64MB or 128MB.

If it's 64MB, you'll want to figure out a way to make it 128MB. I don't believe you can actually do that in-place if you've already expanded your image to the full 160GB. You may have to re-do the upgrade (assuming you still have the original drive(s).)

If it's 128MB, then you need to find a way to run mkswap. I was able to easily do this via telnet on all of the stand-alone boxes I upgraded with "-s 128". I never did figure out how to do it on a DirectTiVo without going through all sorts of extra hacking tricks. There may be instructions around and if so you'll need to find them (or maybe someone can follow-up with the details).

Good luck!

wr9966

02-06-2003, 11:36 AM

My drive A died and I had to 80GB drives floating around. I did not have a backup of the drive so I downloaded a virigin copy of a backup for a HDR112 and then RESTORED it to BOTH of my new 80GB drives using mfsrestore -s 172 blah blah blah /dev/hdc /dev/hdc

My TIVO is working and booted up with out a hitch. But I wonder if I am going to have problems with this in the future.

Thanks.

stormsweeper

02-06-2003, 12:04 PM

Originally posted by wr9966
My drive A died and I had to 80GB drives floating around. I did not have a backup of the drive so I downloaded a virigin copy of a backup for a HDR112 and then RESTORED it to BOTH of my new 80GB drives using mfsrestore -s 172 blah blah blah /dev/hdc /dev/hdc

My TIVO is working and booted up with out a hitch. But I wonder if I am going to have problems with this in the future.

Thanks.

I hope you were more careful typing that in while working than here. -s 172 won't work correctly, but -s 127 will.

Robert S

02-06-2003, 01:31 PM

The second part of post three describes how to increase swap while upgrading the A drive of a twin drive TiVo. You aren't doing that.

All the system partitions are on the A drive, so it looks very different to the B drive (up to 16 partitions instead of just 2).

If your swap partition is already 128Mb then you can just manually initialise it as in post 1. If your swap is only 64Mb then you can't permanently increase the size of your swap because there's no spare space on the disk. You'll just have to do the rescue when needed.

The point is to find out which root partition is the active one. Mounting it isn't part of the fix itself.

To return the partitions to their original order you do exactly what you did before - the operation is self-inverse.

If you have 64Mb of swap, when you do CPen's thing to read the logs you'll see 'activating swap' and a number around 65 million.

Michael248363

02-06-2003, 06:25 PM

The planets must be aligning against me or something.

Couple of questions:

1. What is a command that I can issue that will tell me definitively whether or not I'm looking at drive a or drive b? I connected the drive from my DTiVo that was at the end of the cable and set as master, but I think it's drive b and not drive a.

2. What is the command to show what is connected to hda, hdb, hdc, hdd?

3. Is there a command that will show me how many partitions are on a particular drive?

4. Apparently I can't access backdoors because I'm running version 3.1. So I guess the only way that I can view the log now is to mount the drive. What would be the commands to mount the necessary partition, and where is the log file located?

5. I couldn't get edit_bootparms to work, it says it can't find the file. I'm booting from the MFS Tools 2.0 CD is there anything I need to do before typing the edit_bootparms line to get it to work?

Thanks again.

Michael248363

02-06-2003, 08:34 PM

Thanks Robert! I now have the Green Screen of Life!

I am still a bit curious about the questions I posted earlier. But now on to the next half of my problem. How can I fix the swap file problem so that this doesn't happen again?

Thanks again!

sskraly

02-09-2003, 05:22 PM

Sorry, still a bit confused after reading this thread:

How do I upgrade from a 40+80GB unit (which was previously upgraded from a 15GB to 15+80 to 40+80, always preserving recordings) to a 40+120GB unit?

In other words, I'm upgrading the B drive, and I assume that I need to increase the swap, AND I want to preserve recordings. Most of this thread seemed to discuss replacing the A drive.

Thanks,
Sam

mrtickle

02-10-2003, 06:40 AM

You're definitely right that you need to increase the swap.
Swap has to go on the A drive.
So, you can't have a "40+120" setup - you must make the 120 the A drive.

Use New Hinsdale UPGRADE CONFIGURATION #6 to combine everything onto a new 120GB "A" drive.
Then use mfsadd to make the spare 40GB drive your B drive.

HTH

sskraly

02-10-2003, 07:46 AM

Aha--brilliant! Thanks!

One other question: if my B drive has a few potential bad blocks (failed the Read Verify test in WD Data Lifeguard), is there any command line switch to add to the mfsbackup to let it coast through the errors (similar to the dd conv=noerror,sync switch when using the dd method)?

mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc

Thanks again!

sskraly

02-10-2003, 08:46 AM

OK, I tried Upgrade Config #6 and it's claiming that the backup won't fit on the target. I've got:

hda: 78125000 sectors (40000MB), CHS=4863/255/63
hdb: 156301488 (80026MB), CHS=9729/255/63
hdc: 240121728 (122942MB), CHS=238216/16/63

I'm running:

mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -s 127 -xzpi - /dev/hdc

and I get this during the mfsbackup scan:

Source is 15 hours upgraded to 95 hours upgraded to 127 hours...

Uncompressed backup size: 113434MB

"Restore failed: Backup target not large enough for entire backup by itself"

Any ideas? Could it have anything to do with the 120GB drive coming up as 16 logical heads, whereas the others have 255?

Thanks in advance...

Robert S

02-10-2003, 06:23 PM

You need to follow the second past of the third post in this thread. Use dd to clone the A drive on to the new one, follow the instructions to manually create a larger swap partition and then use mfsadd to expand to a 120+80Gb.

Or, if you /have/ to replace the 80Gb drive (faulty?), dd the 80Gb on to the new one and then use mfsadd to expand, but keep a copy of the 'rescue' maneuver (first half of post three) handy as doing this will break the TiVo's ability to recover from a green screen.

Robert S

02-10-2003, 06:34 PM

Michael: To get any of these things to work on a Series 1 TiVo you have to boot byteswapping. If you manage that, the answers to most of your questions become obvious.

pdisk is the tool to manipulate the partition table. If you invoke pdisk -l /dev/hdX it'll list the partitions on the drive you designate. If you run pdisk without -l it'll enter an interactive mode (be careful!) where pressing p prints the partition table.

A drives have lots of different partitions, B drives have just two (or, at least, very few) MFS partitions, so the difference is obvious.

You can't fix the swap problem permanently without deleting your recordings because there's no unused space on the disk. The space used for the 'rescue' maneuver is only temporarily unused, which is why you have to back out to the original config when the TiVo recovers.

Michael248363

02-10-2003, 11:40 PM

Thanks Robert. I ran pdisk and listed the partitions, based on what I found I've got a couple of questions. I've abbreviated to only include the relevant partitions that I reordered so that I could get past the GSoD reboot loop. I've since re-reordered the partitions so 8 is 7 and 7 is 8.

7: Swap Linux Swap 262144@75685952 (128.0M)
8: Ext2 Root 2 262144@75423808 (128.0M)

So if I'm understanding this right, it looks like my swap file partition is 128MB, the same size as the rescue partition. If that is true, why can't I create a swap file that is 127MB in size? Is there something else on the drive that would prevent me from using the entire drive to create a 127MB swap file? If the partition is 128MB, the when I did the upgrade, did I create the partiton correctly, but just not create/initialize the swap file? If so, do I just need to run mkswap. If so, what are the parameters that I should use to get 127MB of swap file?

I just want to make sure I've exhausted all possibilities and that if I can't fix it to prevent future problems, I want to understand exactly why. Plus, I also want to understand it better. Like I said, my experience with Linux is pretty limited.

Thanks again for the help.

Robert S

02-11-2003, 07:20 AM

It looks like you used -s 128 after all.

I did suggest that you check for that and if you had done that you could rescue your TiVo by following the instructions in the first post to run mkswap against that partition.

Although the partition labels are messed up, you could just leave things the way they are.

Michael248363

02-11-2003, 11:06 AM

I couldn't remember what option I ran when I did the upgrade and didn't know how to check the size of the partition earlier and since I've got 3.1, I can't enable backdoors to check the logs.

So running /sbin/mkswap -v0 /dev/hdc8 (using the right drive of course) will create the proper swap file.

I understand everything about the command except for the -v0. I saw in the help for the program that you could also do -v1. What is that option for?

Just trying to understand it better.

Robert S

02-11-2003, 11:51 AM

They changed the way swap works after the kernel that (Series 1) TiVo uses was compiled. -v0 tells mkswap to make an old-style partition (limited to 127Mb). -v1 is the default and creates the new style partition. Unlimited size (?), but not compatible with a Series 1 TiVo.

I think Series 2 TiVoes should be able to use a new-style swap partition, but I don't have confirmation of that.

davidk

02-11-2003, 05:55 PM

I need some advice!

I revived my DSR6000 from the GSOD by using the inactive swap partition method described by Robert at the top of this thread. I let my DirecTiVo fix itself and I swapped the partitions back. I made a backup image of my 3.1 TiVo. However, now I'm getting frequent reboots and I fear that the only way to really fix my TiVo is to clear my hard drives (160G A Drive and 120G B Drive) and restore a backup.

Here's my question: is it ok to use the 3.1 backup that I made after TiVo self-repaired from GSOD or should I go back to my original backup image (I made it back in 2/2002) with a system version that I don't remember?

Also, when I restore, I plan to use MFS 2.0 (to get increased speed in navigating menus) and increase swap to 127MB. Can I do this with the old backup image from a year ago (if that's the backup I should use)?

Thanks to everyone for all of the great advice and help! I have enjoyed a 245-hour DirecTiVo due to the efforts of those on this board.

--David

Michael248363

02-12-2003, 12:03 PM

A couple of questions that are probably pretty basic if you understand Linux:

1. Is there any way to tell if a partition is set up correctly to use a swap file without using backdoors? I.e. commands on the MFS Tools CD that would show a directory listing of the swap file.

2. When you issue the mkswap command, does it utilize the entire partition regardless of partition size for the swap file (up to the 127MB max, of course).

I've looked at both of my DTiVoes (DSR6k, both running 3.1 software), one has a 128MB partition for the swap file, the other has a 64MB partition. I have no idea why they are different. I thought I upgraded them using the same commands, but apparently I didn't.

rfairch1

02-14-2003, 09:46 AM

I have Series 2, 80hr, bought maxtor 120 hd, wondering if I use mfs 1.1 tools or whatever would be best, adding the 120 as a second drive, would I be affected by the swap issue?

Thanks
Roger

Robert S

02-14-2003, 11:22 AM

The threshold for a Series 2 is 180Gb, so adding a 120Gb drive to an 80Gb one will break mfsfix without additional swap.

MFS Tools 1.x won't help you very much.

If you use mfsadd to add the drive without increasing swap, your TiVo will work, but you will have to use the 'rescue' maneuver from the third post in this thread if your TiVo green screens.

rfairch1

02-14-2003, 03:22 PM

Robert,
Thanks for the reply.

If I increase the swap with the -s127 will that address the problem? Or is this just a risk that may/will happen if I upgrade using the original 80 and add the 120....

Or is there a method I can use / tools that will give a good result?

Thanks again.
Roger

Robert S

02-14-2003, 06:46 PM

Normally I'd advise you to upgrade replacing the A drive with the new one, thus increasing swap with -s 127 and then add the old A drive as a B drive.

However, there have been some reports of problems increasing swap on the 80Gb S2's and I haven't been following the debate on that (the problem may not be real).

Hinsdale's How-To should have the answers you need.

weaknees

02-20-2003, 03:23 PM

We've tested added swap on the S2s pretty fully at this point, and we don't see any problems. We thought we saw one at one point, but we couldn't confirm or recreate it.

We've been adding extra swap to all S2 upgrades that we can, and we haven't seen any problems related to it.

Michael

jeaton

03-09-2003, 05:51 PM

I have a Sony T60 which I upgraded to have a 120GB+40GB with mfstools2 using the -s 128 option (before the problem with -s 128 became known).

My tivo recently got stuck in the green screen reboot loop. I pulled the drives, mounted them in my PC, and checked the logs to find that the swap partition was invalid, as I suspected. (I was getting the swapon: invalid argument error.)

I tried repairing the swap partition with
mkswap - v0 /dev/hdc8
(with my tivo's A drive attached as hdc, obviously). This failed to fix the reboot loop. I tried it again without using the hdc=bswap option, but it still failed.

In both cases, the logs still showed swapon: invalid argument.

I then booted with hdc=bswap, and ran
mkswap -v0 /dev/hdc8 130048
to tell it to use exactly 127MB of space (in my 128 MB partition) as swap. I returned the drive to my tivo, where it proceeded to boot to the green screen, sit there for about 15 minutes (running mfsfix, I presume), and then rebooted and came up just fine.

I don't know why I had to specifically pass a size to mkswap on my system, but it did seem to work.

Thanks much to everyone who contributed to this thread. The infomation provided was invaluable to me in diagnosing the problem my Tivo was having and finding a workable solution. I owe you all a beer.

Robert S

03-10-2003, 06:52 AM

That's odd, on my system mkswap gave a warning 'Truncating to <large number>' and automatically produced a 127Mb swap partition in a 128Mb hole.

jeaton

03-10-2003, 11:22 AM

Originally posted by Robert S
That's odd, on my system mkswap gave a warning 'Truncating to <large number>' and automatically produced a 127Mb swap partition in a 128Mb hole.

I also got the truncating message, but it still didn't appear to properly intitialize the swap area. After running mkswap without the size, the TiVo still logged errors about swap, and still failed to make it through mfsfix.

:confused:

mrtickle

03-10-2003, 02:16 PM

Presumably different boot CDs use different versions of linux (remember linux is running on the PC) and could be running different versions of "mkswap"?

ndwek

03-11-2003, 07:52 PM

I am upgrading a previously upgraded Tivo and am having a problem with the pdisk command from the post, "How to fix your TiVo if it gets stuck on a green screen", the section marked "Upgrading Twin-drive Tivoes".
I previously upgraded the tivo from a 20GB single drive by adding an 80GB drive B. The original 20GB drive is starting to go so I'm replacing it with a 120GB drive and I'm preserving the recordings (upgrade configuration #4 from Hinsdale how to using MFST2).
I've done the dd and now want to fix the swap. Booting from MFST2 boot CD byteswapping is no problem. I run pdisk, "pdisk /dev/hda", also no problem. After typing "C" I am asked for the First block. I type "12p" and get an error of "Bad partition number".
Using the p command to print the partition table I see that the partition numbers only go up to 11 and have confirmed that this is the same on the original A drive.
What am I doing wrong?

Thanks,
Norman

ndwek

03-11-2003, 10:50 PM

So I've realized that if there are 11 partitions then I can't specify 12p because it doesn't exist, hence the error. Now my problem is that no matter what I do I can't create a partition of any sort.
I've tried specifying 11p and 10p as well as adding the base and length of the last partition to come up with the next free base but no matter what I do I get the error message:
"requested base and length is not within an existing free partition"

Any idea what I'm doing wrong?

cojonesdetoro

03-12-2003, 09:15 PM

I looked at the regular linux man pages for swapon and found that you can create swap space using a regular file on the ext2 file system and not need to create a partion. I tried this on my tivo and it seemed to work. The log messages showed the added swap space.

First I did this to create a blank 64MB file:

dd if=/dev/zero of=swapfile bs=1024 count=65536

Then I ran this command to format it as swap space:

mkswap ./swapfile

Then I did this to add it as swap space:

swapon ./swapfile

I then rebooted my tivo to undo this and started writing this post. Here are my questions:

Is this useful if put in early in the boot process or does a GSOD not even load Linux?

Could this help those that have stuttering or other performance problems?

Are there any pitfalls? It seemed to work...

Robert S

03-13-2003, 06:44 AM

It'll work, but it isn't very useful.

For a start, on an unflashed DTiVo or any Series 2 the lock-down will revert the TiVo to its original condition.

So, assuming you have a Series 1 standalone, you could use this technique to increase swap.

swapon activates swap in the current session, not permanently. This is fine if you have a shell on your TiVo so you can run swap on manually, but the shell won't activate during a GSOD. You'd therefore have to add swapon to rc.sysinit (or, probably preferably, fstab).

The GSOD is the only thing that uses a lot of swap - if you check now, you'll find your TiVo is only using a few megs of swap. Adding more unused swap will not cure any stuttering or other performance problems you may be having.

If you run into problem with the GSOD running out of swap, then the 'rescue' maneuver described in the third post of this thread is probably a better choice than creating swap in /var.

cojonesdetoro

03-13-2003, 09:05 AM

Originally posted by Robert S

If you run into problem with the GSOD running out of swap, then the 'rescue' maneuver described in the third post of this thread is probably a better choice than creating swap in /var.

But the rescue maneuver involves opening the Tivo and mounting the drive(s) in your PC which, for some, is logistically difficult. It would be nicer if there was an easy way to increase the amount of swap available for GSOD without having to do an mfsrestore -s 127 to a new drive.

My situation is such that I can only do it while losing recordings. My wife would kill me if I lost all the episodes of OZ and I don't have the time to download them to VHS.

mrtickle

03-13-2003, 12:23 PM

You could use merge.tcl to join the episodes together into blocks and then run off 8 hours' worth each night while you're asleep. You should get them all off the tivo in a few days?

Robert S

03-13-2003, 01:39 PM

OK, sure. If you have a Series 1 stand alone, with a shell on it and you upgraded it over the limit and you're worried about running out of swap, then, yes, it might be a good thing to do.

I suggest you modify /etc/fstab so the extra swap gets activated as early as possible.

dhwebb

03-19-2003, 09:47 PM

OK. I've looked, seen one post about it and no comments about it. That is permanently swapping partition 8(swap) and 9(/var). Somebody claimed that /var is 128M. Could /var survive on the 64M partition. If so, is this a good fix.

Any problems that could arrise.

I have a S2 80hr +120G(b) on 3.2 w/64M swap.

ron_b85

03-24-2003, 04:17 PM

Originally posted by dhwebb

I have a S2 80hr +120G(b) on 3.2 w/64M swap.

Which tool(s) did you use? MFS Tools 1.1 or 2.0?
I'm looking to *just* add a 120G drive to my Sony S2's 80G, but don't
want to go through the steps of pulling the 80G out, backing up, etc...
I'd just like to "bless" the 120G and drop it in place (weaknees are able
to do this with their 'upgrade kits'...)

Thanks for any pointers!
:)

dragon

03-27-2003, 12:48 PM

I just finished upgrading my 40gb single drive DSR 6000 to 120gb x2 using MFStools 2.0. (TIVO version 3.1)

I thought I read everything I needed before getting started. I even stopped my upgrade at 70% after having waited 4 hrs because I realized that a swap file increase was needed. So I added the -s 128 that I was reading about and then the next day, I find this string of messages about the 128 swap file problem. DAMN!

Can I just live without this swap file?
I'm 10 hrs into this thing and am tired of it.
I may just bite the bullet and redo it with -s 127.... but this really does work right? If i do a -s 127?

By the way... any of you know why my recorder now says only 225 hrs recording time when I go to system information? I thought it would be more.

Oh yeah... where is the backdoor code for TIVO version 3.1 I tried the code I saw here for 3.0 and it didn't work.
Dave
daveskim@msn.com

Robert S

03-27-2003, 02:45 PM

Read the first post in this thread. There are a number of options there that you can use to initialise your swap.

DTiVoes have 32Mb of RAM, so you may find it's OK with no swap. Series 1 SA's only have 16Mb of RAM and misbehave badly without swap.

ehayes

03-28-2003, 05:43 PM

Yea, I've recovered from the green screen, using the alt boot partition temp fix!!

MANY THANKS for having this here!!!! I get my "stuff" back!! ;-) I am so Fricking Happy!!!!

So... As I need to give back the alt. boot partition.... Do I have to watch ~everything~ to get back to an empty state so I can reformat with a correct swap? I used the -128 before the swap problem was known?

Thanks guys!

-eric

Robert S

03-29-2003, 11:35 AM

If you used -s 128, you have a 128Mb partition without a valid swap signature in it, so you can just use mkswap to initialise it instead of doing the 'rescue'.

You can probably leave it in the 'rescue' configuration as the empty swap partition is the same size as the root partition you replaced it with.

See the first post in this thread for very detailed instructions on what to if you used -s 128, although, having done the 'rescue', it should be pretty obvious what to do.

theJakeLuck

04-01-2003, 11:55 PM

Green screen of death... I knew what it was even before visiting this forum to find out what to do about it, and I was scared. I encountered my first GSOD today and I think I know what to do to fix it. Months ago I successfully upgraded my AT&T, series 2, v.3.0 from single 40gig to twin 120gig hds. I dd copied my entire original 40gig drive directly onto new 120gig, expanded, and married to another 120. I did not increase my swap file. I think it's still 64MB because I'm now stuck in boot up loop including GSOD. Is there a way to expand to 128mb without losing everything? I did create backup image of my original hard drive before recycling it in my PC.... however, now I can't find the backup file. It's either lost or deleted. Can anyone help me with a backup image for my particular TiVo? I think if I can restore that to my new large A drive I can then expand my swap file using -s 127 and hopefully green screen of death is gone????

Robert S

04-02-2003, 10:44 AM

Did the 'rescue' maneuver from the third post in this thread work for you?

There's no way to expand swap permanently without losing your recordings, but you can do the 'rescue' as many times as necessary.

If the 'rescue' does save your TiVo, you can make a compressed backup from your current drive set.

It would be a good idea to run diagnostics (PowerMax, or whatever) on the disks to check this isn't a hardware problem.

theJakeLuck

04-02-2003, 02:59 PM

I have not yet tried the 'rescue' maneuver. I'll give it a shot tonight.

ksucat90

04-10-2003, 07:10 PM

Ok, first here is the scenario. I have a Series 1, with 14 hrs, used BlessTivo and added a 60 Gb Maxtor about 2 years ago running v 3.001100. I wanted to upgrade to a single 120Gb WD drive so, I used the MFS tools 2.0. After booting MFSTOOLS cd, I ensured all drive registered proper sizes. I made a backup of both drives using the following cmd.

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

unmounted and rebooted and attached new 120Gb drive to hdc (Secondary Master)
Then attempted to restore to new drive using the following cmd

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

I restored, but on cleanup gave me a bunch of Inode errors. I attached the new drive to my Tivo and booted, got the “Almost there” screen, it rebooted, gave me “Almost there again” and has gone to the GSOD.

So I went back and tried the restore expanding at the same time with this command.

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

Same problem. GSOD. So question is, what have I forgot to do? The original drives still work, so I assume the backup is good. (816mb) I even did the complete process again to check myself.

Any help would be appreciated.

Robert S

04-10-2003, 08:33 PM

Rather a strange choice of thread to post this in, but never mind.

I would think the hard drive is faulty - run the manufacturer's diagnostic utility on it before you go any further.

Davin

04-13-2003, 01:00 PM

Given this whole discussion, what is the current consensus/advice for upgrading a Sony SVR-3000?

I've purchased a 120GB disk to add - and burned an MFS tools 2.0 CD, as per Hinsdale instructions.

How unsafe is it to just do a mfsadd? Or should I go through one of the longer procedures, such as: make my 120GB my new single-drive first (while growing swap with -s 127), and then mfsadd my original 80Gb afterwards?

Thanks.
Davin.

Robert S

04-13-2003, 01:22 PM

How worried are you about the Green Screen of Death? If it happens you'll have to do the rescue. That's all you need the extra swap for.

Davin

04-13-2003, 01:40 PM

And the rescue, using the secondary root partition as temporary swap, should always work and be safe, (as long as I remember to revert it!) in case my TivO does GSOD?

Robert S

04-13-2003, 03:02 PM

It does seem to be working well for people (I don't get lots of PM's or posts asking why it doesn't work).

mfsfix can't fix every possible problem, but the rescue does seem to allow it to run.

If you think about it, doing the rescue is functionally equivalent to increasing your swap with -s 127.

Davin

04-13-2003, 03:20 PM

Is there no way to create a swap partition on the second (i.e. the new, being added) drive? Will the kernel not find it? (Since spreading swap partitions over multiple spindles is usually a good thing anyway.)

Robert S

04-13-2003, 05:12 PM

Yes, but to activate the swap partition you'd need to modify /etc/fstab. The Series 2 TiVoes are locked down, and this would restore the original /etc/fstab and prevent it activating.

Davin

04-14-2003, 07:44 AM

Thanks. That makes sense.

So I guess that I'll just go ahead and to the mfsadd upgrade, and hope that the TiVo never needs to run mfsfix. :-)

Thanks again.
Davin.

deek_man

06-15-2003, 01:24 PM

I have a series 1 Phillips that that I upgraded to two 100 GB Maxtor hard drives about a year ago. Unfortunately, I upgraded before the swap problem had been found and I ended up with 64 MB swap. This morning I discovered I had the green screen reboot loop.

I used the rescue operation described by Robert S. in the third post of this thread using the newest version of MFSTools and everything seemed to go fine although when I used the r 8 7 command (my inactive root partition was 7), followed by w and y, mfstools said that it was unable to confirm (reread) to make sure the writing had been completed because the device was "busy". I assumed that this response probably wasn't a problem and that Tools had successfully renumbered the partitions.

When I returned the A drive to the Tivo, I got the green screen reboot cycle but it appeared to be rebooting even more quickly (i.e., staying on green screen for even a shorter period of time) before rebooting. Since the instructions said the reboot should be "occasional", it troubled me that the cycling of the reboot was so fast. Nevertheless, I let the machine run for a couple of hours and the fast reboot/green screen cycle still continued.
I then restored the original partitition numbers as per the Directions (F) and the reboot/green screen cycle slowed a great deal. Although the green screen said to keep the phone line plugged in, I did not do so since there was no mention of the need for that in the rescue instructions. I renumbered the partitions one more time (assumedly going through the rescue operation one more time as in instruction D) and once again got the fast reboot cycle.

I have a pretty good understanding of what the problem is but my understanding of Linux is very poor. I realize I could have a problem other than the swap problem but I sure could use some help with the following questions:

1) Does the fast reboot cycle normally happen just after the rescue operation?

2) How long should the rescue take?

3) Is there a way to tell whether my partitions are in their original configuration or in the rescue configuration?

4) I notice when I boot up using MFSTools, it lists the various partitions , what they're beinused for and something like sz = XXXX where XXXX is a number. Is that the size of the partition?

3) Does it matter if the phone line is plugged in?

4) Any suggestions at all would be helpful since I'm at a point where I really feel pretty lost. I suppose I could just use my backup file to recreate the A drive and start from scratch marrying the two drives, etc. with the new improved instructions but I hate to lose all my programs, season passes, etc.

Thanks in advance for any help you could give me.

Robert S

06-15-2003, 02:03 PM

If the rescue works, then the Green Screen should stay up and fix the problem. As I said, some people have reported that their TiVo rebooted once or twice before the GSOD cleared, so there's no need to panic if the GSOD reappears after the first reboot, but it takes about 10 minutes for mfsfix to allocate all the memory it needs. If it reboots before that, then it's not doing any useful work.

With 64Mb of swap it seems to take about 4 minutes for the system to realise that it doesn't have enough memory and kill mfsfix. The fact that you're rebooting faster suggests that you do not have any swap in the rescue configuration - therefore it runs out of memory immediately.

That column does give you the size. You'll see that the swap partition is 64Mb and the kernel partitions are 128Mb.

Apparently the GSOD can download files from TiVo if it discovers that something important has become corrupted. I doubt it's important in most cases. I didn't mention it because it's a normal part of the TiVo setup, and the GSOD tells you to plug it in!

I would check the TiVo logs (you'll have to mount the /var partition and read /var/log/messages) to verify the swap situation. I would try running mkswap on partition 7 again. I would also run diagnostics on the A drive just incase there's a bad block in an awkward spot.

deek_man

06-15-2003, 02:48 PM

Robert S., thanks lots for the quick response. I did use pdisk to list the partitions and the r 8 7 command did seem to be switching the swap from the 64 megabite swap partition 8 to partition 7 at 128 mb and vice versa. But I'll go back and do the things you suggested and then let you know what happens. Thanks again.

deek_man

06-15-2003, 03:23 PM

I did go through the mkswap routine again and in pdisk, it did reorder the inactive root partition 7 with the swap partition 8. Partition 7 became the swap partition at 64 mb and partition 8 became the secondary root at 128. Isn't that how they should look? I still get the rapid cycling green screen and reboot and it continues indefinitely. Two quick questions:

Could you tell me more precisely how to read the message log? I was able to mount hda9 but was unsuccessful at trying to read the messages since I know so little about linux commands.

Second, I have the original TiVo hard drive that came with the machine last year along with the software upgrade it downloaded when I first used the machine. If I disconnect both of my upgraded drives and put it on as the master and the machine works, I would assume that means it's either the drive or a problem with the software or swap, wouldn't you agree?

Update: I did put the original hard drive back in the machine and it works fine.

Robert S

06-15-2003, 03:49 PM

We're using a trick here to fool Linux into using a different partition for swap. The entry in /etc/fstab declares that partition 8 is to be mounted as swap on boot.

So the rescue involves relabeling partition 7 (or possibly 4) as partition 8 and using mkswap to make it a swap partition. As the kernel partition is larger than the original swap partition, this buys us enough extra swap for mfsfix to run.

The position you want to be in, therefore is to have a 128Mb partition 8 and a swap signature on it. Run pdisk and/or mkswap as necessary. I take it you did include the -v0 to make it use the old style of swap signature?

I did describe how to read the log in the original post that's linked in the inital post.

deek_man

06-15-2003, 05:08 PM

Thanks. Your last post was very informative. It always is easier when you have some sense of what you're doing rather than blindly writing commands. I guess I need to take a Linux lesson.

I believe I've found my problem but not the solution. I have been using the print (p) command in pdisk to see what the partitions look like after performing the intended changes. No matter what I do, i can't seem to get 128 mb of swap in partition 8. I have been using the makeswap command in the third post:

mkswap -v0 /dev/hda7

If I then go into pdisk and use the p command, it doesn't show partition 7 as swap but rather still as root 2. Thus, if I use the reorder command, partition 8 doesn't end up with a swap signature. Maybe that's why my reboot/green screen cycling was so quick. The software didn't see any swap in partition 8. I've also reordered first to make partition 8 the root with 128 mb and then tried to use mkswap on 8. Didn't work either. When I use mkswap, the info comes back with some reference to a program called Busybox and it appears to work as it gives no error
messages. Can you think of any reason why my mkswap command isn't changing the partition 7 to swap? I'm using mstools2 noj as currently posted at the Hinsdale howto site.

BTW, I did look at the messages in /var and there are lots of them but I really don't know what they mean. Is there something in particular I should be looking for?

Robert S

06-15-2003, 05:53 PM

mkswap doesn't change the label in the partition table (I don't think anything except pdisk uses those!), it writes a small amount of information into the partition itself that declares that this is so many bytes of valid swap. You would expect to see partition 7 called swap and partition 8 called Root 2 when in the rescue configuration. You may need to run mkswap on partition 8.

If your swap is broken there will be about three lines saying something like 'cannot activate swap' - it's easier to find when it's broken 'cos when it works there's only one line declaring that swap activated OK. The lines appear before the clock is set, so they'll be on the 1st of Jan 1970.

I don't know why mkswap would give problems, it's always worked fine for me. Busybox is just a container application that includes a lot of twiddly Unix commands in one file. It's a much more efficient use of disk space than having each command be its own file. Saying nothing at all when things have worked, but giving a confusing error message when something's gone wrong is typical Unix.

deek_man

06-15-2003, 10:57 PM

Robert S., thanks so much for all of your helpful responses. I learned a great deal about Unix and hopefully, this exchange will help others trying to do the rescue operation.

Your last response about Unix pretty much saying nothing when things work and giving a confusing message when things don't work was really helpful. Also, your message about trying to get 128 mb in partition 8 as well as your message indicating that pdisk doesn't really show that as swap helped lots.

So what happened? I'm a little embarrassed to say that when I copied the third message in this thread where you explain the rescue procedure, I pasted it into a word processing program to print it and use it. The program (WordPerfect) apparently due to font differences and printer output, placed two dash marks for the large dash which is in front of the -v0 switch in the mkswap command. So, just as you suggested in one of your responses, that switch was not working since I was using two dash marks when I tried mkswap. When you pointed out that the version of mkswap could be important, I went back and looked at your original post and realized that only one dash mark should be there. (Obviously, I know nothing about Unix.) Also, your last post indicating that pdisk wouldn't show that partition as swap made me realize that I was looking for problems in the wrong place.

So, in short, your original directions produced exactly the fix they were supposed to. When I finally appropriately produced the 128 mb partition 8 with a swap signature, the machine did exactly what your directions said it would do, namely stay on green screen for extended periods and reboot a couple of times and then fix itself. Specifically, the green screen stayed on for about 10 minutes, then tried rebooting, then went to green screen for about another 10 minutes (or perhaps a bit longer) and then rebooted and everything was fixed. (I did, importantly, reorder the partitions to their original configuration after the fix.)

So, in the end, it was the problem with too small a swap partition (64 mb swap for 200 GB split between two hard drives) that caused my GSOD, and, using the right commands it was (or should have been) fairly easy to fix.

Thanks so much for your help and quick responses. I really appreciate it and I'm up and running with my entire sytem restored. Thanks from D.C. to Cabridgeshire.

deek_man

06-16-2003, 08:25 AM

Regarding the above fix and the final step of reordering the partitions back to their original configuration. As long as pdisk now shows partition 8 as 64 mb of swap and partition 7 (my inactive root) as 128 mb of root, I should be ok at the next software download. Right?

Thanks again for your help.

Robert S

06-16-2003, 08:42 AM

That's the original configuration. On the next software upgrade it'll format partition 7 as Ext2 and put your new software on that partition.

mutant

06-16-2003, 10:49 PM

Hi all:
MFS 2.0.
After several tries I got to the point of adding the 14th partiton for the swap drive.
This was a problem - pdisk reported an invalid partition when I tried the 14p parameter to C.
I realized the partition table still thought the drive was 40gig rather than the current 120; so I reinitialized the partition table and reentered the partition info (reordering so it was identical to the orgional).
I then created the new swap partition with 14p and did the reordering - all seemed well.
When I try to run mfsadd it gives me lots of errors - am in byteswap mode (booted with vmlnoma hdc=bswap - hdc is the drive I am upsizing)
Second MFS drive needed: No such file or directory
Second MFS drive needed2: Illegal seek
Second MFS drive needed: No such file or directory
Second MFS drive needed3: Illegal seek
mfs_load_volume_header: Total sectors(77242368) mismatch with volume header(3363200)
mfs_volume_header: loading anyway
mfs_load_zone_map: Primary zone map corrupt, loading backup.
mfs_load_zone_map: Seconday zone map corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!
Unable to open MFS drives.

I have put it back into the TIVO and it seems to be working fine.
Help!
Mark

Fuzz

06-17-2003, 05:28 PM

I just added a 160 GB drive (as the 2nd drive) to my Series II 60 hour Tivo. I didn't realize the swap issues until I was done. I'm not too afraid of the GSOD fix, but since I only upgraded a few days ago, I am wondering if I have a chance to redo the upgrade and add the swap at the same time without losing any significant recordings.

My plan is as follows:

1) Using the option to restore and expand (while saving recordings and increasing swap), copy my current 60 GB drive over to the 160 GB drive (and overwrite whatever is on it now)

2) Add the existing 60 GB drive as my "second" drive.

Will this work, or since I already added the 2nd drive, will something bad happen? I figure that there aren't many (if any) recordings on my 2nd drive and I don't care if I only lose a few new programs.

Robert S

06-17-2003, 06:08 PM

The problem is that the 160 is already part of a 'married' set. If you restore a current backup to the A drive your recordings /might/ survive (if I recall correctly you do want -p for an S2, but not -s 127 or -x), but it's far from certain.

That would reverse the upgrade and then you could copy the recordings over to the new drive.

TBH, though, I wouldn't bother. Just make sure you've got a copy of the MFS Tools CD and a print-out of the rescue procedure in case you ever need it.

mutant

06-17-2003, 07:40 PM

Got the mfsadd problem worked out - I needed to have both drives in in order to do the add. Worked flawlessly when I did this.
Anyone doing this second upgrade (40g A drive to 120G A drive when you have aleady added a 120 as B) will need to look out for the problems with not being able to dd copy the drive and then update the partition table.
I understand there is a newer version of pdisk that will allow you to specify that to determine the drive size by means other than the partition table. Otherwise you will have to initialize the partition table and manually reeneter the data. This is a very difficult acticity to undertake!
Mark

Robert S

06-17-2003, 07:52 PM

I'm glad you've got it working. You are the first person to report this problem with pdisk. The procedure is lifted from the TiVoMad script (it does this if you tell it your TiVo is >140Gb). I assume Trevor's version of pdisk is the same as on the MFS Tools 2.0 CD.

As ever, comments on any of the procedures at the top of this thread are welcome. The manual swap procedure is by far the least well tested (because it fixes a very specific problem). I fervently hope that manually rebuilding the partition table isn't part of most people's experience (how would I write that up?

Fuzz

06-17-2003, 07:55 PM

Ok good point. Does anyone have any odds on the GSOD? I mean, all I can tell is that it is "rare." How rare are we talking, once in the lifetime of the Tivo, only when the hard drive is about to fail anyway, etc.?

Originally posted by Robert S
The problem is that the 160 is already part of a 'married' set. If you restore a current backup to the A drive your recordings /might/ survive (if I recall correctly you do want -p for an S2, but not -s 127 or -x), but it's far from certain.

That would reverse the upgrade and then you could copy the recordings over to the new drive.

TBH, though, I wouldn't bother. Just make sure you've got a copy of the MFS Tools CD and a print-out of the rescue procedure in case you ever need it.

Robert S

06-17-2003, 08:03 PM

I don't have any numbers for you, 'rare' is the best I can do. Fixing GSOD's is not the major topic in this Forum, so given the number of TiVoes out there, I would infer that most TiVo owners will never see a GSOD.

The rescue procedure is not all that onerous. Many people have used it successfully.

aaronkn

06-21-2003, 12:14 PM

Robert S,

Sorry if you've already posted about this somewhere (I'll keep looking), but I'm trying to do the recovery method in the 3rd post of this thread, and can't seem to get going. I'm new at working with this stuff.

I made a boot CD with MFSTools 2.0 as directed, and connected my TiVo A drive to my computer. I accidentally swapped with my Secondary drive at first, but then switched it with my Primary drive afterward. I booted with the CD. Now I noticed that you said Series2 Tivos are NOT byteswapped, so I skipped that part.

I got a prompt on the screen that says "boot". I tried typing the first command of "edit_bootparms hda -r", but was given a "command not found" response. I then tried the "mount" command, but that was also not found. I stepped away from the computer for a minute, and then it started running some commands on its own. When it was done, I had a prompt of "/#". I tried both of the previous two commands at this prompt, but they didn't work this time either. The mount command responded with "unknown device".

Is there anything that you can tell me to help me get going?

Thanks,
Aaron

Robert S

06-21-2003, 12:22 PM

Not sure why edit_bootparms wouldn't run. I don't have an MFS Tools 2.0 CD on hand to check it. I would guess you just mistyped the command name.

Mounting an unknown device also suggests a typo. If you try to mount an empty partition it should ask you to specify the filesystem type.

Did you have your A drive on primary master?

Do you see the TiVo partition table printed during boot-up?

aaronkn

06-21-2003, 12:36 PM

Ok, I'm now a little concerned that when I first plugged my Tivo drive into the Secondary place on my PC, that WinXP may have put a signature on it. I'm not sure. Anyway, I'm not sure about the partition table....but one thing I did notice is that I saw "hde" somewhere, instead of "hda". So I just tried typing "mount /dev/hde4 /mnt" and the prompt came back with no message. When I then type "ls -l /mnt", it comes back with 33 responses, all with the same date/time.

Robert S

06-21-2003, 12:42 PM

If the drive is no longer bootable in the TiVo, you'll need MakeTiVoBootable (http://tivocommunity.com/tivo-vb/showthread.php?s=&threadid=117404).

hde suggests you've plugged the drive into the wrong socket. It doesn't look like it's a problem, though, just substitute hde for hda and carry on.

aaronkn

06-21-2003, 12:59 PM

Well, I plugged the drive back into Tivo, and it goes through the same GSOD boot loop. Since that's what it was doing before, I'm guessing I'm ok as far as the WinXP signature problem?

So, how do I know which partition to mount? I tried both hde4 and hde7, and both seem to mount. When I mount hde4, "ls" gives me 33 listings. When I mount hde7, I get 31 listings. All the listings have the same date. Do I just pick one and move on the the "mkswap" step?

Robert S

06-21-2003, 01:09 PM

How can they have the same date?

The problem is that if you pick the wrong one you'll erase your TiVo software! If you really can't get edit_bootparms to work, perhaps something like "dd if=/dev/hde count=1 | strings" would work (assume strings is on the MFS Tools disk. That should include something like root=/dev/hda4.

You can back up your root partition before you format it. Assuming you have a writable partition on /mnt (which might be tricky for you), you can do "dd if=/dev/hde4 of=/mnt/tivo4.bak"

aaronkn

06-21-2003, 01:45 PM

Oops, sorry . . . I meant all the listings FOR THAT MOUNTING have the same date. Each of the two mounted partitions have a different date from each other. hde7 has a date of Jun 2 2002; hde4 says Apr 23, but doesn't give the year. I'm believe that was this past April....I think that's when ver 4.0 downloaded, so hde7 should be the inactive one.

I typed "mkswap -v0 /dev/hde7"...it said "mkswap: warning: truncating swap area to 130752 kB" then "Setting up swapspace version 0, size = 133885952 bytes"

Then I ran the pdisk command, and it gave me a prompt "Command:" I typed "r 8 7" <enter>, then "r 5 9" <enter>, then "w", then "y". It came back with pdisk: re-read of partition table failed (device or resource busy) Reboot your system to ensure the partition table is updated.

I'm not sure what I'm doing wrong.

Robert S

06-21-2003, 02:44 PM

Yes, if it doesn't give the year it means this year (or even, within the past year).

Don't know what's wrong with pdisk, can I hazard a guess that it's to do with your using the wrong disk controllers?

Anyway, did you reboot the system and check that the partition table has been updated as pdisk requested?

aaronkn

06-21-2003, 02:56 PM

I rebooted, and if I try mounting hde7, it says "looks like swapspace - not mounted" "mount: you must specify the filesystem type"

Does this mean that it was successful in making the swapspace, and that I should now put it back in Tivo to let it try and fix itself?

Thanks

attivoplayer

06-21-2003, 03:08 PM

I have been having a great time using mfstools 2.0 backing up and restoring configruations on my ATT Tivos however, I have found that whenever I restore (typically with):

mfsrestore -zpi /mnt/dos/tivo.bak /dev/hda

Everything works fine except, any time my tivo calls up or i force a call, I get the error:

"Failed While Preparing Data"
after it downloads from the service.

BTW, I have v.4.0 system

Any help appreciated!

Robert S

06-21-2003, 05:37 PM

I don't know what's wrong there. You might want to start a thread for this to get a bit more attention.

philhu

06-22-2003, 08:48 PM

so, since it looks like my svr-2000 will be getting no more system upgrades, is it worth while to make my hda7 (nonused system partition), a swapfile of 127meg and adding it to /etc/fstab to be mounted on startup along with the hda8 swap?

svr-2000 has only 16meg memory and crashes on some apps, so my question is whether adding 127meg more swap will stop the out of memory crashes during normal operation.

Robert S

06-22-2003, 09:23 PM

It couldn't hurt to try. I've no idea what'll happen if it does try to take an upgrade in that config, though, so key an eye out for new updates, however unlikely.

Try it and see.

philhu

06-23-2003, 08:49 AM

ok, so I would do a

mkswap /dev/hda4 130752
swapon -a

The 130752 is the largest swap file allowed, correct (127.6875meg)

Also, how would I put it back to a std partition later, is there any way to do it while in the tivo? Is the 'mkfs -t ext2' command available on the tivo?

And finally, could I not just take hda4 and format it as ext2 (I used mfstools 2, so the partition is empty), then build a swapfile on it of
64meg, put that in ther fstab, so if an upgrade ever did come down,
there would be plenty of room for the system (System uses about 40meg):

# dd if=/dev/zero of=/dev/hda4/swapfile bs=1024 count=65376
# mkswap /dev/hda4/swapfile 65376
# sync
# swapon /dev/hda4/swapfile

Even better, how about a 32 meg file on /var? I know it is 25% of the drive, and tivo can end up wiping /var if it gets full, but it never gets over 40% in my experience.

Anyone have the 'free' command compiled for Tivo?

Robert S

06-23-2003, 10:51 AM

Why don't you try it as straight swap to see if it fixes your stability problem? I doubt it will unless you've got a memory leak (in which case scheduled restarts of the offending app would be better). 64Mb is already a 4:1 over-commit. An unmodded TiVo will only use a little bit of swap when it runs the indexer.

It's mfsfix that requires vast quantities of memory (up to 127Mb with the standard kernel).

When the software update comes in, the TiVo will reformat the inactive root partition ready for the new software (I think mke2fs is the command you're thinking of, mkfs is usually a script that knows which format utilities are installed). Similarly, mkswap will fill the partition (up to the 128Mb limit) if you don't give it a number.

A swap file on /var could work as long as there's room. Does the TiVo download a huge tarfile containing the new software into /var when it upgrades? In which case, again, your TiVo might be fine except during an upgrade cycle.

First, find out if more swap is the solution to your problem

roup1

06-26-2003, 05:27 PM

Hi Robert:

I have a Sony SAT-T60 w/ a failed A drive. My current config is 40GB A and 80GB B. I'm planning on restoring the backup image onto a new 120GB A drive. I would also like to re-use my 80GB as the B drive.

When restoring the backup image, can I also use the '-s 127' command to increase my swap size? Also, can I use MFS 2.0 for the restore? If so, what would the command be?

Thanks for your help...

Robert S

06-26-2003, 06:45 PM

You will need more swap for that configuration to recover from a green screen, so you'll definitely want to use -s 127. There's virtually no difference between backups made by difference versions of MFS Tools, so there's no problem using MFS Tools 2.0 for the restore (the difference is a single bit added to indicate if the backup is from a Series 1 or 2 TiVo (to deal with byteswapping issues), just incase you're curious).

You can just restore to both drives with -x and it'll make a twin-drive setup for you. MFS Tools 2.0 won't care that your old drive was once a B drive in a different configuration.

The command would be the same as in Hinsdale:

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

roup1

06-27-2003, 12:13 AM

Thanks for the great info! So I use - xpi instead of - xzpi?

Thanks again...

hopefulboydy

07-11-2003, 07:59 PM

I've been searching through this thread as I recently upgraded my previously upgraded Series 1 SA tivo by adding a second 80G drive. I have previously upgraded (6 months ago) by changing the stock 30G A drive to 80G. In my original upgrade I replaced the A drive after copying the contenst and put my original drive in a safe place. Since I already had a backup I never made a new back up but just added the new B drive to my A drive as per instructions.

Since I saw a lot of people have been having problems with none or not enough swap space, I enabled backdoors and had a look to see if I still had the original amount of SWAP (64Meg) and I did. My worry is that now that I have a combined 160 G I have read in this thread that I need more swap space to avoid the GSOD happening later in life. I have also read in this thread that 64M should be fine. To be safe I would rather increase my swap space to 127M but cant seem to find out how to do this safely. Most fixes I see are for creating swap space when the upgrade caused it to be lost.

How do you make 64M swap into 127M ?
I am very grateful if someone can give me the bash prompt instructions to do this. Sorry if someone already covered this as I looked through this thread and had trouble finding it. Thanks.

Robert S

07-11-2003, 09:11 PM

You don't have any free space on the drives to increase swap.

See the third post in this thread for an emergency measure that can get you through the GSOD, should you ever get one.

hopefulboydy

07-12-2003, 12:48 PM

Thanks Robert S. I had a look through that post you mentioned and at the end it has the following:
------------------------------------------

Run pdisk and create a new partition:

pdisk /dev/hda

C
12p
128m

You'll also be asked for the partition label and partition type. "Linux Swap" and "Swap", WITH the quotes, are the 'official' answers, but TiVo doesn't check this detail.

Swap the partition labels around

r 12 8
r 9 13

Write and exit:

w
y
q

Then prepare your new swap partiton

mkswap -v0 /dev/hda8

and you can now complete the upgrade with mfsadd as normal:

mfsadd -x /dev/hda

You should now find your TiVo boots to give you extra space and report a 130 million byte swap partition in the logs.
---------------------------------------------
I was thinking that this is my best option as the post does mention that you dont have to wait for the green screen to occur before you increase the swap. I dont know if it will work for me at the minute with my two drive set up. If it doesnt, I might try taking both drives out, formatting them to start afresh, then restore to single A drive and go from there.

Any comments anyone ?

thanks.

Robert S

07-12-2003, 01:01 PM

Yeah, but, you need to have some empty space to create that extra partition. Your drive is already full. The rescue is the only option open to you.

hopefulboydy

07-12-2003, 01:06 PM

Robert S, I am having a problem understanding that I have no extra space as I have 160 G of drive space and dont have that many shows recorded. Could you explain what you mean , thanks,
hopefulboydy

Robert S

07-12-2003, 01:12 PM

Although you 'don't have that many shows', the empty space in the recording regions is not available for other uses. When you ran mfsadd during the upgrade it allocated all the unused space on the drive for recordings.

The method you referred to requires you to make the new swap partition before you run mfsadd, while there is still unallocated space on the drive.

hopefulboydy

07-12-2003, 01:18 PM

Robert S,
thanks for clearing that up.
Looks like I am left with hoping I never see that green screen and dealing with it if I do
OR
start from the beginning with two clean empty drives and my back-up file (making sure I increase the swap size at the correct point this time).

thanks for pointing me in the right direction

nysteelo

07-19-2003, 04:58 AM

Originally posted by Robert S
There's no way to expand swap permanently without losing your recordings, but you can do the 'rescue' as many times as necessary.

Is this true for a Dtivo that doesn't have a GSOD?
I upgraded my Dtivo with 2 120gb drives and I think (it's been over a year now so my memory is foggy) I added the wrong swap space at the time. I knew I would have to eventually change it but as long as my system was up and running with the increased recording space I got lazy and put it off (I know, I know........stupid :rolleyes: ). My tivo can show the channel guide and still play back recordings but can not display channels or change channels and just displays a black screen with a message about "call ext. xxx to subscribe" and wont let me change the channel to one that I receive normally. I'm not sure if this is a swap space problem or hardware problem. when I look into the system info it reads no programing data past the current day. When I force a call it connects and does its thing but still displays the same data message. I'm assuming this could be the hard drive going out and the partition where the channel guide info is written is going bad. Just in case I purchased 2 more new 120gb drives and I wanted to dd the recordings on to these while increasing to the correct swap space but I ran across this quote after trying to research my problem.

If someone has run across this before and figured it out.......please do tell. I have searched this forum and not run across this yet, but if I absolutely have to I'll have to just place my old backup image on the new drives and run the 2.0 util the correct way and scrub all those recordings :(

Any help will be much appreciated. Thanks.

Robert S

07-19-2003, 07:35 AM

I doubt it's related to swap. You have 32Mb of RAM plus 64Mb of swap, which is plenty for normal operations. The GSOD is the only thing I know of that take a lot of memory. You can try restarting the recorder to clear out any memory leaks if it's been running for a long time, but TiVoes seem to run happily for months without consuming their swap.

It couldn't hurt to do the rescue to see if it helps, but I think your problem relates to a hardware issue rather than swap.

If your new drives are the same size as the current ones, I don't see how you can increase swap and keep your recordings.

nysteelo

07-19-2003, 09:25 AM

Thanks for the reply Robert S.....

Yeah, I'm leaning towards it being a hardware issue as well.

I think I have a way to preserve my recordings or at least view them once before deleting them and reusing the drives. I have 3 Dtivos currently, 2 of which are used on a regular basis and have both been upgraded with larger drives. The third one is hardly used and I have been putting off upgrading it until now. I just thought about using the 2 120gb drives from the tivo that is acting up and putting it into the unused Dtivo temporarily so I can watch all those shows before deleting them and put the new twin drives I just bought into the Dtivo that needs to be fixed. My only concern is if this is possible without causing any conflicts with the software looking for its previous card or a chip id that is unique to the original box.

Any thoughts?

Robert S

07-19-2003, 09:38 AM

You can't move recordings between DTiVoes because of the encryption. You have to do a 'Clear and Delete Everything' reset to make the drives work on an different mainboard.

nysteelo

07-19-2003, 09:45 AM

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.

Michael248363

07-19-2003, 03:07 PM

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.

Robert S

07-19-2003, 06:08 PM

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.

tjon1

07-20-2003, 12:19 AM

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!)

Michael248363

07-20-2003, 01:00 AM

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?

Robert S

07-20-2003, 07:04 AM

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.

Michael248363

07-20-2003, 09:27 AM

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?

tjon1

07-20-2003, 10:52 AM

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.

Robert S

07-20-2003, 12:10 PM

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.

philhu

07-21-2003, 10:48 AM

pdisk for tivo?

My tivo does not seem to have this.

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

Thanks

Robert S

07-21-2003, 11:07 AM

pdisk (as an x86 binary) is on the TiVo boot CD's and floppies.

Michael248363

07-21-2003, 11:45 PM

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.

Robert S

07-22-2003, 07:58 AM

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.

Michael248363

07-22-2003, 12:26 PM

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

Robert S

07-22-2003, 01:01 PM

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?

Michael248363

07-22-2003, 01:27 PM

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.

Robert S

07-22-2003, 01:39 PM

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.

Michael248363

07-22-2003, 03:41 PM

Thanks. You're *dim* ideas are much better than my *bright* ones.

tjon1

07-22-2003, 09:44 PM

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!

Robert S

07-23-2003, 07:21 AM

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.

tjon1

07-23-2003, 10:14 AM

Robert,

Ok, obviously I'm more than a bit confused! Again please excuse my profound ignorance of these matters.

So, I could do one of the following?:

Plan 1

1. Install my original tivo drive as primary master and the new 160 drive as secondary master.

2. Boot off mfstools cd.

3. Issue the following command:

mfsbackup -aqo - /dev/hdc | mfsrestore -xpi -s 127 - /dev/hda

4. Ctrl-Alt-Delete

5. shutdown, re-install 160 in Tivo

This would do the trick? Is the syntax correct?

or,

Plan 2

Could I backup the present 160 drive and then restore from the backup (thus saving the last few days recordings)?

Would this be the way to do it?:

1. Connect the 160 drive to the secondary master connector (assuming my c: drive is primary master and cd is either primary or secondary slave).

2. boot off the mfstools cd

3. Issue the following commands:

mkdir /mnt/dos

mount /dev/hda1 /mnt/dos

mfsbackup -6o /mnt/dos/tivo.bak /dev/hdc

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

umount -f -a -r

4. shutdown pc

5. Remove 160 drive and re-install in TIVO.

Is this correct?

BTW, the instructions for mfstools 2.0 (on the cd) shows the following command:

mount /dev/hda /mnt/dos

I couldn't get the drive to mount or backup until I changed "hda" to "hda1". The Hinsdale instructions use the "1" but the doc file on the mfstools distribution does not. What is the significance of the "1"? If "hda1" is the proper designation, why does "hdc" not need a numeral after it?

Also the instructions in the section on restoring say:

"Take (one of) your new drive(s) and set it's jumpers to Master. Connect the drive to your secondary IDE channel to make it Secondary Slave."

Wouldn't doing this make it the secondary master?

Thanks beforehand for your help!

Robert S

07-23-2003, 11:00 AM

Plan 1 is fine.

I keep telling people, ignore all the docs on the MFS Tools 2.0 CD and Tiger's FTP site. There are several very important mistakes. Work from the current version of Hinsdale. As you've discovered, it contains fewer errors.

/dev/hda or hdc is a pseudofile that contains the entire contents of the hard drive. As MFS Tools is reimaging a whole drive this is what it needs to access.

/dev/hda1 is a pseudofile containing the entire contents of the first partition on the hard drive. The partition contains a filing system that mount can integrate into the Unix system.

I don't know where you got

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

from, but it should be

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

This will save your settings, but no recordings. If you want to copy any recordings you'll have to clone the whole drive with dd or an MFS Tools pipe.

Yes, jumpering the drive as master makes it secondary master (I assume that's fixed in the current Hinsdale too).

So, to go back to your question on swap, if you do either or those plans you'll have 127Mb of swap and 137Gb of drive space. You have enough swap to add a second 160Gb drive to give you 2x137Gb without breaking mfsfix.

There's a nice symmetry in that the maximum swap you can get from MFS Tools and the normal TiVo kernel is exactly enough to support the maximum amount of disk space you can get with the normal kernel.

If you want to use the patched kernel to go to even larger sizes then you need to make arrangements to get even more swap.

landofloons

08-05-2003, 06:38 AM

I have been through this thread twice now and I am still confused. Here is where I am at:

Sony SAT-T60 DTivo working well as 40A + 80B, upgraded using MFSTools 2.0. I am doing a second upgrade to 120A + 80B and want to save the recordings. So far I have dd'd the 40GB drive onto the 120GB drive and put the whole works back into the Tivo. So far so good. I have not yet done an mfsadd because I have only a 64MB swap file and would like to increase it's size before I do this.

I have studied the first several posts to this thread carefully but am unable to get the pdisk instructions to work. I am using Kazymyr's Tivo boot CD and have 13 partitions to start with. I have also read stories of pdisk trashing part of the drive.

I would like to find an understandable way to increase the size of my swap before I do an mfsadd on my drive set if possible...

Thnks to everyone who has made this much information available......

deek_man

08-05-2003, 04:23 PM

Sometime back, I posted a number of messages to this thread and got some great help (especially from Robert S.) about repairing a GSOD which needed to be performed on my Philips 112 upgraded to two 100 GB Maxtors but with only 64 mb of swap. I recovered from the GSOD (with Robert's help) but shortly thereafter, I occasionally found one of my drives repeatedly clicking which could be fixed by rebooting (i.e., unplugging, plug back in). This happened about 4 times over about 2 months only to end up with a new GSOD. Clearly this seemed to indicate a bad drive which was probably resulting in the GSOD. This time, when repairing the GSOD loop, I decided to check the drives and, sure enough, the A drive was defective. I backed up the drive (season passes, setup, etc. only) and I returned the drives to the TIVO and ordered a warranty replacement which I received. (The old drives still work even with the defective sectors, at least for a period of time.) The new drive Maxtor sent is 120 gb. I had originally planned on doing a dd from the bad A drive (since it's still operating) to the new drive but now I'm more inclined to utilize the extra space on the 120 gb replacement. Three questions (and thanks for the help in advance):

1) Can I dd the bad 100 gb A drive to the new 120 gb drive and expand it while saving all the recordings or will that foul up its association with the B drive.

2) When I expand the new A drive, can I increase the swap to the needed larger amount?

3) Or should I just blow off the recordings and restore my backup to the A drive and expand, bless the two good drives and simultaneously get the needed swap with the -127 switch?

Robert S

08-05-2003, 04:45 PM

You probably have 13 partitions on your a drive now, so you can upgrade it once more before the partition table is full. Perhaps you'd prefer to save this option for a later upgrade to a /really/ big drive?

So either, don't expand at this point, or copy the B drive on to the new one and then copy the A drive on to the old A drive (it'll take forever, but you did ask).

If there's any spare space on the drive, then the third post of this thread explains how to manually expand the swap partition. Because the new swap partition replaces the old, this doesn't add to your partition count.

deek_man

08-05-2003, 04:55 PM

Thanks. One more question. You said I could "So either, don't expand at this point, or copy the B drive on to the new one and then copy the A drive on to the old A drive."

I'm not sure I understand. the old A drive is defective. So should the above direction say "copy the B drive on to the new one and then copy the A drive on to the old old B drive ."? If I'm correct, when I copy the B drive on to the new drive, will all 120 gb be recognized? Also, how can I tell if there's room on the drive for expanded swap (or maybe that's in the post that you pointed out). Thanks again.

Robert S

08-05-2003, 08:10 PM

Yes, old B drive. You'd have to use mfsadd to get the extra space on the B drive, but because there are no system partitions on the B drive, this doesn't hurt so much (you're limited to 6 MFS pairs in total, so there are still limits).

You couldn't expand swap permanently in this scenario unless you edit /etc/fstab to activate a swap partition on the B drive.

deek_man

08-13-2003, 01:08 PM

As described about 4 messages back, I had a bad A drive on a Philips series 1 causing a GSOD. I first decided to blow off my recordings and get the extra swap so I backed up the previously upgraded 2 drive system to get a condensed 15 hour backup. The computer drive to which I sent the backup was the primary slave (hdb), the Tivo A drive was connected to primary master (hda) and the Tivo B drive was connected to secondary slave (hdd). (It's a long story...don't ask why.) So I backed up the previously expanded (2x100GB) hard drive system using:

mkdir /mnt/dos

mount /dev/hdb1 /mnt/dos

mfsbackup -6so /mnt/dos/tivo.bak /dev/hda /dev/hdd

Everything seemed to go just fine with the backup and also things seemed to go well when I restored my condensed backup to the new larger A drive with:

mfsrestore -s 127 -zpi /mnt/dos/tivo.bak /dev/hda
(drive with backup file on hdb, new larger A drive on hda)

However, the new larger A drive restored from the backup would not work on the Tivo and rebooted over and over. I did this a couple of times and it just didn't work so I'm assuming the defective A drive had some bad sectors right where it mattered thus producing a bad backup image. I then used dd to copy the old defective A drive to the new (larger) drive using:

dd conv=noerror,sync if=/dev/hda of=/dev/hdd bs=1024k
(old defective A drive on hda, new larger A drive on hdd)

While several input/output errors were reported during the dd, it did finish to completion and the new A drive with the original B drive do seem to work fine together. Two questions:

1) Any thoughts on why the original restore didn't work? (I do have an older backup file from when I first upgraded but decided to just go with the dd for now.) Maybe the bad sectors on the defective A drive screwed up the latest condensed backup file?

2) Is there any way to utilize the extra 20 GB on the 120 GB A drive that I copied (with dd) from the original defective A drive?

Any help would be appreciated.

winders

08-15-2003, 09:00 PM

Originally posted by mutant
Got the mfsadd problem worked out - I needed to have both drives in in order to do the add. Worked flawlessly when I did this.
Anyone doing this second upgrade (40g A drive to 120G A drive when you have aleady added a 120 as B) will need to look out for the problems with not being able to dd copy the drive and then update the partition table.
I understand there is a newer version of pdisk that will allow you to specify that to determine the drive size by means other than the partition table. Otherwise you will have to initialize the partition table and manually reeneter the data. This is a very difficult acticity to undertake!
Mark Anyone know where I can find this new version of pdisk??

Thanks,

Scott

djr195

08-24-2003, 12:17 AM

I just successfully upgraded my SA series 1, and my PC now will only reboot using the MFStools boot CD. Windows boot discs (both floppy and CD) don't work. Please help!

PC is a PIII-500 running WinXP. The primary HD is an IBM formatted in FAT32. I followed Hinsdale's 2.0 upgrade How-to.

Thanks for any help!

mohanram

09-08-2003, 05:55 PM

I originally had a TiVo Series 2 60Hr unit which I upgraded using Hinsdale's old instructions - I took a backup and added a 160GB HD as drive B. I have had it working for almost 18 months now. I now find that my TiVo is repeatedly rebooting after powering up and reaching the GSOD (as you folks call it).

How do I go about solving this ( with / without losing my recordings)? This thread and other threads of interest are too long and discuss many scenarios. What do I need to do in my scenario? I also read about the swap file size. Is that the issue here? How do I fix it so that this does not occur in the future?

Thanks
Raj

Robert S

09-08-2003, 05:59 PM

You have exceeded the 180Gb limit (for Series 2's). You need to do the 'rescue' from the third post of this thread.

philhu

09-09-2003, 12:08 PM

well

gsod on a jam-packed 240gig tivo worked with Robert S's method (making hda7 a swap file).

It took 6 hours, but it fixed it!

svr-2000!!!!

Thanks!

Yog

09-09-2003, 07:51 PM

Heh. Reading through this thread, it's unfortunate that Linux needs 'mkswap' at all.

Other Unix OSes, like Solaris just use whatever you point them to, be it a raw partition or file, with no need for preperation by a utility like mkswap.

You guys really had me going in this thread! The whole time I was thinking "why not just do a mkswap -v0 while the drive is in byteswap mode ??? Why wouldn't that work ???" Had me afraid for a while that MFST2.0 was really broken. I should have just skipped to the end. :)

I have a Philips SA that came w/ a 15GB Quantum drive (30 or 15 hour ? I forget). Back in the days of BlessTivo and Dylans boot floppy, I bought a replacement Quantum A drive (20 GB), and a new Maxtor 80 GB B drive, and used the 'dd backup/copy onto new A drive and bless B' style upgrade, which has served me well since around Nov 2000. (Incidentally, I had the drive spin down problems, and being the lazy sort, I didn't feel like pulling the Tivo back out of the TV stand and pulling the drives out, etc. So instead I cross-compiled the 'hdparm' utility to a TiVo PPC binary, and fixed the problem by uploading it to the TiVo via console port/zmodem. I subsequently released the binary and announced it on this forum.)

Now, my 3 year old Quantum A drive is starting to have fits (verified A drive from looking at the logs). It's been through two multiple-reboot GSOD episodes thus far, but has 'recovered' from both. BTW, it seems it's somewhat normal for the GSOD to loop multiple times before recovering. I let mine go through the GSOD/reboot loop for about 3 hours before it finally came up and booted fully. Looking through the logs, it seems like it reboots every time it gets a hard error from the drive, the comes back up and restarts the fix. Not sure if it skips the bad sector or if the drive remapped it to a spare, or what.

Fearing that the A drive is likely to go completely kaput any moment now, I plan to use MFST2.0 to transfer my old A drive and B drive (about 95GB) to a new 120GB maxtor A drive, then, once the 120GBer has been verified to work, add the 80GBer back in for a 200GB Tivo :-).

My original plan was to use the the MFST2.0 bootable CD on my 4 IDE controller PC with this command( orig A & B on hdf & hdg, new drive on hdh):

mfstool backup -Tao - /dev/hdf /dev/hdg | mfstool restore -r 2 -s 256 -xzpi - /dev/hdh
Then reboot in byte swap mode for hdh, and do:

mkswap -v0 /dev/hdh# (# being standard swap partition, which I forget) Preparing the swap area.

I know I'll only get ~127MiB of swap, but I wanted to have the space there for a 256MiB partition if I want to use the patched kernel later.

I have a couple questions about this. First, do I need the "-s" flag in the backup command to 'divorce' the drives ? The readme for mfstool indicates that "-s" and "-a" are 'somewhat' mutually exclusive, but doesn't give a clear description of why. The Hinsdale guide option #6 shows this command without the "-s" command, so I presume this works.

Second question, has it been proven that the increased block sizes (ostensibly sacrificing some granularity/space for less mem usage/more performance) break the mfsfix program during a GSOD ? The thread seemed to think this was the case for a while, then the opinion went the opposite way (block size doesnt matter). Is the consensus now that using the block size arg is OK ? If the answer is unknown, perhaps I'll do a mfsassert after the copy and before the re-adding of the 80GB to the TiVo to see if it fails :-).

Of course, I'll use MFST2.0 to make a backup of the TiVo drives w/o the streams first before doing any of this, just in case :-). I already have a backup of my stock original drive which still has a 1.3 image on it :-).

- Yog

Yog

09-10-2003, 07:22 AM

Ok.

I think I've answered my own question. I backed up my existing 2 drives with mfstools from the boot CD using the typical command.

I then took my new 120GB Maxtor and restored the backup image to it using:
mfstool restore -r 2 -s 256 -zxpi /mnt/hdf1/backup.bak /dev/hdc

After this completed, I rebooted with byte swapping enaled on the new TiVo drive, and ran pdisk and mfsinfo to make sure everything looked OK. Then I initialized the swap partition using:
mkswap -v0 /dev/hdc8
It initialized the swap (truncating the swap space to around 128MiB as expected). I then mounted up the root partition, and added a line to give me a shell on the DSS port.

I popped it back into the TiVo, and it booted up fine. Everything was there, season passes, etc. The logs all looked good. It recognized and used the swap space, etc. Now for the acid test! I ran 'mfsassert -please', and it went POOF! Rebooted, and GSOD came up. After about 10 minutes or so, it rebooted again, and came all the way up!

Here are some log entries for the curious:

Jan 1 00:00:14 (none) kernel: Activating swap partitions
Jan 1 00:00:14 (none) kernel: Adding Swap: 130744k swap-space (priority -1)

Sep 10 11:44:35 (none) kernel: Filesystem is inconsistent - cannot mount!
Sep 10 11:44:37 (none) kernel: fsfix: mounted MFS volume, starting consistency
checks.
Sep 10 11:46:08 (none) kernel: I-Nodes:
Sep 10 11:46:09 (none) kernel: I-Node table size is 131072 entries for 100000 ac
tive nodes max.
Sep 10 11:46:09 (none) kernel: FsId high-water mark is 0x285dd6
Sep 10 11:46:11 (none) kernel: Pass 1 - scan and analyze
Sep 10 11:47:20 (none) kernel: reconstructing zone buddymaps
Sep 10 11:47:22 (none) kernel: synchronizing...
Sep 10 11:47:22 (none) kernel: volume marked as needing database cleanup
.
.
Sep 10 11:47:22 (none) kernel: volume marked as needing database cleanup
Sep 10 11:47:23 (none) kernel: scanned 54082 files, covering 13207 extents
Sep 10 11:47:23 (none) kernel: 145200 application pages in use
Sep 10 11:47:23 (none) kernel: 24635392 media pages in use
Sep 10 11:47:23 (none) kernel: Inode table collision details
Sep 10 11:47:23 (none) kernel: 28961 hash collisions in node table.
Sep 10 11:47:23 (none) kernel: 20 hash collisions in longest run.
Sep 10 11:47:23 (none) kernel: 11 hash collisions in longest busy run.
Sep 10 11:47:23 (none) kernel: 10849 files aren't in their primary hash location
s.
Sep 10 11:47:23 (none) kernel: Allocation Details
Sep 10 11:47:23 (none) kernel: 41961/53858 application inline files, 77.91%
Sep 10 11:47:23 (none) kernel: 47.60% wasted space (0 bytes) in normal applicati
on region
Sep 10 11:47:23 (none) kernel: 50.39% wasted space (0 bytes) in inlined applicat
ion region
Sep 10 11:47:23 (none) kernel: 224 media files
Sep 10 11:47:23 (none) kernel: 99.27% wasted space (0 bytes) in media region
Sep 10 11:47:23 (none) kernel: Fragmentation:
Sep 10 11:47:23 (none) kernel: average extents/file is 0.24
Sep 10 11:47:23 (none) kernel: worst extents/file is 18
Sep 10 11:47:23 (none) kernel: expected extents/file (approx) is 3
.
.
Sep 10 11:47:23 (none) kernel: Media region:
Sep 10 11:47:23 (none) kernel: zone contains 24776704 pages: 24373248 allocated;
403456 free
Sep 10 11:47:23 (none) kernel: inode allocations match allocated page count
Sep 10 11:47:23 (none) kernel: buddy-map is internally consistent, 403456 pages
marked free
Sep 10 11:47:23 (none) kernel: zone contains 212959232 pages: 262144 allocated;
212697088 free
Sep 10 11:47:23 (none) kernel: inode allocations match allocated page count
Sep 10 11:47:23 (none) kernel: buddy-map is internally consistent, 212697088 pag
es marked free
Sep 10 11:47:23 (none) kernel: fsfix: 0 fatal errors, 0 warnings.
Sep 10 11:47:23 (none) kernel:
Sep 10 11:47:25 (none) kernel: mfscheck scan begins
Sep 10 11:51:08 (none) kernel: Checking reference counts
Sep 10 11:51:09 (none) kernel: All reference counts are OK.
Sep 10 11:51:09 (none) kernel: mfscheck scan ends
Sep 10 11:51:12 (none) kernel: mfscheck: 0 fatal errors, 0 severe errors, 0 warn
ings.

So it appears everything works fine as long as you initialize the swap, etc. The "-r 2" doesn't seem to have any ill effects on fsfix and mfscheck.

The next step will be copying the entire old disk set over to the new one, so I get my recordings back.

- Yog

Robert S

09-10-2003, 09:19 AM

Yes, even the 16Mb blocks that you get with -r 4 don't affect mfsfix. The confusion was caused by embeem who reported the problem before the details of mfsfixes swap requirements had been determined (he thought -r had broken it when infact he didn't have enough swap). -r 2 is the default for mfsrestore, so there would be a lot of dead TiVoes out there by now if it was a problem.

Interesting observation on why the GSOD sometimes restarts when it does have enough swap.

Yog

09-12-2003, 02:47 AM

Well, it's done. Seems to be working fine. After trying out my 'small' backup, and seeing it work, etc, I took the drive out of the TiVo and put it back onto the PC and did a backup/restore pipeline to copy all my streams, etc. Everything copied in about an hour (only about 80MB of stuff to back up).

I put it back into the Tivo and ran the new single drive for a few hours making sure everything was OK. Everything seemed fine, so I added the 2nd drive back in (80GB) with mfsadd, put everything back in, and voila, 252 hour TiVo.

I did have to turn off the 'auto spin down' with hdparm, which is, thankfully, included as part of the TiVo OS in 3.0 (I had to cross compile and upload it for 1.3).

There's only one problem so far. I get the odd "hitch" now and then. This is accompanied by a 'drive seek' sound. The only log entry I get when this happens (and it doesn't always generate a log entry) is:
Sep 12 06:44:36 (none) Scheduler[124]: SimAndSched:774590 [<?>] (Cnd2,Chg2,Unscd0,Scd2)
Sep 12 06:44:36 (none) TmkSink::Trace[118]: Audio out of A/V sync. Flushing and resyncing. Diff=136127 abuf=6016
Sep 12 06:44:36 (none) TmkSink::Trace[118]: pts=166354905, videoSTC=1168231104512
Sep 12 06:44:36 (none) TmkSink::Trace[118]: timeInBuffer=22560, bitrate=24000

I'm hoping it's just the drive finding the 'bad sectors' and remapping them. It only happens once in a while, so it's no big deal, but is kind of annoying and worrisome. Any ideas ?

Also, looking at the hdparms args, I see an interesting one:
-M * set drive streaming-media mode (0/1)

This seems like something one would want to turn on, but so far, I've been afraid to try it. I have two Maxtor drives. I'm not even sure if they have this sort of capability. Is this something safe/desirable to turn on ? Should I try it ? In recent Linux's, the "-M" flag is acoustic management, not "streaming media mode". Maybe this is a TiVo specific modification ?

- Yog

ostrom

09-18-2003, 09:00 AM

I am having a problem using MFS 2.0 (see my separate post), but also have a question about whether my overall approach will work.

MFSINFO reports that my current system is using 6 partitions, 4 on my original A drive, and 2 on my (previously added) B drive. My plan was to merge these onto a single drive, while expanding the swap space (30GB+60GB onto a 120GB drive), then add back in the 60GB drive.

Rereading this thread makes me wonder if I will be unable to add back the B drive for lack of available partitions. Is this correct?

Thanks for all the help!

Andy Ostrom

raiders

09-30-2003, 05:31 PM

I have a directivo dsr6000 with 2.52. I now have a P4 card to replace the P3 card so it should then update to 3.1. I only have a 64MB swap with two 120GB drives and I have had to do the GSD rescue several times. Because i may not have reverted the swap after a rescue, i'm now not sure if i have the swap partitions set up properly. I think i understand from the 1st page how to check which is the current swap, however I am confused as if my current swap partition (should it be 4,7,or 8?) is correct or i need to change it again.

Can someone (robert :-) ) please provide the definitive specific partition numbers that i should verify on this system to ensure that the new 3.1 download doesn't thrash the system.

Thanks.

caa

10-13-2003, 10:53 AM

I had my first drive go bad on my dual 120GB tivo. I had first added a 120GB drive to it, then later with mfstools 2 replaced the original 20GB with another 120GB drive.
I did not expand the swap at the time.

When the drive started to go bad, it GSOD'd on me and could not fix it. I didn't know why until I found this thread. Sure enough when I mounted the drives and looked at the logs in /var, I found the fsfix was getting a sig 11. I really didn't want to do the whole change the second root partition to swap, so here's what I did.

I looked and there was only about 12 meg out of 128meg used in the root partition. So I made a 64meg swap file with
# dd if=/dev/zero of=/mnt/swap bs=1k count=65535
then made this into a swap file with
# mkswap /mnt/swap
then edited rc.sysinit and added
'swapon /swap'
right after the swapon -a line.

Installed the drives in my tivo, rebooted and 3 hours later it was backup. With all my shows & season passes intact.

And now I have 128meg of swap
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 14278656 14147584 131072 662282240 57344 4411392
Swap: 134201344 4894720 129306624
MemTotal: 13944 kB
MemFree: 128 kB
MemShared: 646760 kB
Buffers: 56 kB
Cached: 4308 kB
SwapTotal: 131056 kB
SwapFree: 126276 kB

Robert S

10-13-2003, 01:13 PM

Whether you regard that as easier than my version of the rescue is a personal judgement, but it achieves the same result.

However, the reasons I went with the partition-relabeling version were that it avoids editing rc.sysinit (if you get it wrong it'll leave your TiVo unbootable) and, more importantly, it will work on any TiVo whereas anything that involves modifying the root partition will run afoul of the lock-down on anything other than a Series 1 stand alone.

caa

10-13-2003, 02:04 PM

Well I guess since I only have a SA series 1, I didn't know it wouldn't work on other tivos.

I've done unix admin work for close to 20 years, so editing the rc.sysinit script is a lot more familiar to me than changing partitions around.

Plus if I screwed something up, all I have to do is redo the dd off the old drive (6 hours or so) and try again.

I would have liked to expand the swap partition doing the restore, but everything I found about doing this indicated I need to have another drive for the b drive even though I wasn't changing it.

Robert S

10-14-2003, 07:59 AM

You can create a 128Mb partition and swap that for the existing swap partition before you expand the image. Doing it that way gives you a solution that will survive a software upgrade, although for us Series 1 owners, that's unlikely to be an issue any time soon.

mdhoward

11-02-2003, 08:45 PM

I have a question about the fix for the green screen. I followed the instructions exactly on page 1 (3rd post from top) of this post. Hda4 was my inactive partition hda7 was the active one so I followed the intructions on making hda4 the active. Once I get to the end where I renumber my active partition and then I type W and then Y and it does it and returns me to my prompt what do I do next? Is there any special way I have to turn the computer off or any commands I need to type? I just turned the computer off after typing in Y (final step of D) and put the drive back into the Tivo. When I do that it STILL is stuck cycling in the green screen and then reboot every few minutes mode. Did I do something wrong? I know in step E (restoring drive in Tivo) it says to let it run and that it might continue to reboot but that it will eventually return to normal but is this same green screen I was getting before normal?

Robert S

11-02-2003, 09:10 PM

Nothing special to before switching off - you don't have any mounted partitions in this procedure. I'd be looking at the logs (which means mounting the /var partition) and checking that the swap got activated correctly.

As I understand it (and GSOD's are so rare that I've never actually had one on my own TiVo) it takes about 4 minutes for a Series 1 TiVo to realise that it's out of swap and reboot. So if it reboots faster than that you probably have no swap at all (mkswap?). If it reboots more slowly than that then it may be that the GSOD is dealing with bad blocks and is actually doing something useful, if rather slowly.

mdhoward

11-02-2003, 09:58 PM

Thank you for the quick reply Robert. As far as the reboot cycle... it boots and then hits the green screen and stays there for yeah about 4 or so minutes and then reboots and keeps doing this over and over. It was doing the same thing before I tried your method (3rd post) and is still doing it now.

How would I go about doing this?

"I'd be looking at the logs (which means mounting the /var partition) and checking that the swap got activated correctly."

And what you mean by that is once I change it to hda4 I want to make sure that hda4 "got activated correctly?"

Sorry I know next to nothing about doing all this, just have been lucky with following directions on this site.

mdhoward

11-03-2003, 08:12 PM

Ok I think I really messed up this time. I my fustration of not knowing if I did the right thing in activating hda4 I tried the mkswap... on hda7 and then followed the rest of the directions in making hda7 the partition. Well when I put the drive back in the Tivo I never could get out of the welcome screen, I didn't even get to the green screen. I then put the drive back on the computer and tried mounting both drives both coming back saying that both drives looked like swapspace or whatever it says.

Is there anyway I get things back to the way they were before I made this goof? Meaning returning hda7 back I guess to its original state of working right?

Robert S

11-03-2003, 09:08 PM

That won't be easy to fix. You've turned the system partitions with all your TiVo software on it into a swap partition. I wouldn't advocate using a scatter-gun approach when issuing commands to Unix. You are required to know exactly what you're doing.

The system partitions are commong between TiVoes, so if you can restore a backup to another drive you could copy the active root partition off that drive on to your A drive.

mdhoward

11-04-2003, 08:25 AM

Yikes! Ok how would I go about doing that? I have the old original hard drive still that I could pull the needed info from. My main concern is getting the programs off this drive that I am working with now. If I can do that and then just start over fresh from the beginning and reformat this drive then I have no problem in doing that.

Robert S

11-04-2003, 09:59 AM

As long as the old drive has the same version of the software on it (if not, put it back in and get it to upgrade itself), then boot byteswapping (Series 1) and do

dd if=/dev/hdX7 of=/dev/hdY7

and all should be well (that is to say, you'll be pulling your hair out over the GSOD that won't go away...).

mdhoward

11-04-2003, 09:34 PM

Ok I tried that replace hdX with C which was my original drive and hdY with B my drive I have been working with and I get this

0+0 records in
0+0 records out

I put the drive back in the Tivo and nothing...it still sets at the intro screen. Did I not do it right?

Robert S

11-05-2003, 09:06 PM

Unix is case sensitive, so hdB and hdb are different things.

Did you boot byteswapping?

msullivan

11-05-2003, 10:07 PM

I'm looking to upgrade my TiVo Series 2 (240040) such that it'll have the original 40 GB drive and a new 120 GB B drive. Will this cause these so-called "swap" problems? If so, is the easiest way to fix it to simply get a smaller upgrade drive? I noticed it's an easy fix if you can get a prompt on your TiVo, but after searching here I've been unable to find a way to enable backdoors on 4.0 to do that. Thanks in advance for helping me out.

Robert S

11-06-2003, 08:26 AM

You can go to 180Gb on a Series 2 TiVo without having any problems related to swap. I'd recommend making the new drive the A drive, letting it run for a bit and then adding the old A as a B drive if you feel the need for the extra space.

mdhoward

11-07-2003, 08:51 AM

I searched and entered this to boot byteswapping

vmlnodma hdd=bswap

And I used lower cased letters when I was typing in hdb and hdc

Robert S

11-07-2003, 09:21 AM

You need to swap the devices that the TiVo drives are attached to:

vmlnodma hdb=bswap hdc=bswap

NFLnut

11-15-2003, 12:38 PM

Maybe I'm as dumb as a box of rocks, but ..

When I mount hda4, I got something like:

total 4
drwxr-xr-x 2 root root 1024 Jul 23 2001 c/
drwxr-xr-x 2 root root 1024 Jul 23 2001 d/
drwxr-xr-x 2 root root 1024 Jul 23 2001 e/
drwxr-xr-x 2 root root 1024 Jun 10 2001 tivo/

When I mount hda7, I get

drwxr-xr-x 2 root root 1024 Oct 27 07:32 bin/
drwxr-xr-x 2 root root 3072 Oct 27 07:32 dev/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 dist/
drwxr-xr-x 4 root root 1024 Oct 27 07:33 etc/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 etccombo/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 initrd/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 install/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 kernel/
drwxr-xr-x 3 root root 1024 Oct 27 07:32 lib/
drwxr-xr-x 2 10763632 60450406 12288 Oct 27 07:31 lost+foung/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 mnt/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 proc/
drwxr-xr-x 2 root root 1024 Oct 27 07:32 prom/
drwxr-xr-x 2 root root 1024 Oct 27 07:31 sbin/
lrwxrwxrwx 2 root root 8 Oct 27 07:31 tmp -> /var/tmp
drwxr-xr-x 2 root root 1024 Oct 27 07:33 tvbin/
drwxr-xr-x 2 root root 1024 Oct 27 07:33 tvlib/
drwxr-xr-x 2 root root 1024 Oct 27 07:33 var/

Now I'm going to go out on a limb here and make a wild guess.. hda7 is my active partition?!?????? Can someone please confirm or tell me I'm wrong?

NFLnut

11-15-2003, 12:53 PM

I went back and booted with MFSTools 1 and tried the same. This time, the dates on hda4 are the same as hda7 was with the MFSTools boot disc. There are 31 directories now in hda4, and the dates are Jan 2, 2003. In hda7, there are also 31 directories, with the date still reading "Oct 27 07:31"

Why is there now a difference, and which of these (hda4 or hda7) are my active partition? I'm really confused now!

Robert S

11-15-2003, 12:54 PM

Partition 4 looks very strange, but partition 7 looks like an ordinary root partition. As October 27 is only a couple of weeks ago, I'm guessing that was the last time the TiVo took a software upgrade, so I'd be pretty confident that's the active root partition.

If you're still in doubt, try using edit_bootparms to look at the boot block.

[Now you've tried again that looks much more sensible. The TiVo would have taken an upgrade in January and another one a few days ago.]

NFLnut

11-15-2003, 01:00 PM

I couldn't get edit_bootparms to work with either the MFSTools ver.1 or ver.2. As to the Oct 27 date, this coincides with the time that my TiVo started getting the GSOD loop! :rolleyes: I'm just curious as to how hda4 could show "Jun 2001" on MFSTools2 and "Jan 2003" on MFSTools1!

So, I just wanna make sure .. hda4 (the one with Jan 2, 2003) is my inactive partition? What happens if I screw up and pick the wrong partition?

NFLnut

11-15-2003, 01:25 PM

Why does cr@p always happen to ME?!?!

I went through the steps tomake the inactive partition active:

"mkswap -v0 /dev/hda4"

then,

"pdisk /dev/hda"

I got:

Edit /dev/hda -
Command (? for help): "r 8 4"
Command (? for help): "r 5 9"
Command (? for help): "w"
Writing the map destroys ... Is that okay? [n/y]: "y"

I then got:

"pdisk: Re-read of partition table failed (Device or resource busy)
Reboot your system to ensure the partition table is updated.
Command (? for help):"

I tried entering "w" again and got the same response. Does this have anything to do with having booted this time with MFSTools1?

Robert S

11-15-2003, 03:17 PM

I don't know why there would be problems writing the boot block. Perhaps this disk is more broken than it appears? All you can do is reboot the system as suggested and see if the partition table has been rewritten.

As to your earlier questions, the list with c/ d/ e/ and tivo/ was not a listing of a TiVo drive, so having different dates on it is not surprising.

Perhaps the GSOD repeated the download of the system software?

If you run mkswap on the wrong partition, you'll make the TiVo unbootable (won't get past 'welcome').

NFLnut

11-15-2003, 03:24 PM

Well, I guess I made the 'proper' choice .. I'm still getting "powering up," "just a few seconds more," GSOD loops. I'll give it a coupla more hours, then I'm throwing in the towel and dropping a new image on the drive. I just can't spend much more time on trying to save my old recordings.

DCIFRTHS

12-21-2003, 12:32 PM

I can't seem to locate instructions on how to increase swap for a Pioneer 57H. I'd like to use a 300 GB drive. Sorry if I missed this, but obviously I did :o

Would someone please post that information here?

Thank You.

DCIFRTHS

12-21-2003, 12:43 PM

Another question(s) (it's been a while since I've upgraded):

1) It seems that the only reason a DOS/WIN98/WIN ME etc. disk is needed is to pipe the backup to. Is this correct?

2) A WIN 2000/XP disk will corrupt the backup when it writes a signature to the disk. Correct?

2a) If yes, then couldn't I use a NON-bootable HD formatted with a FAT32 partition on it for the backup file as opposed to having a bootable HD connected?

2c) If yes, could this disk be formatted using WIN 200/XP as a FAT32 partition?

Thanks.

lemketron

12-21-2003, 12:59 PM

Originally posted by DCIFRTHS
Another question(s) (it's been a while since I've upgraded):
1) It seems that the only reason a DOS/WIN98/WIN ME etc. disk is needed is to pipe the backup to. Is this correct?
I believe so, but note that the backup image is typically piped to a file on the disk (like "TivoBackup.tar.Z").

2) A WIN 2000/XP disk will corrupt the backup when it writes a signature to the disk. Correct?
A Windows disk will NOT corrupt the backup file ("TivoBackup.tar.Z") but it WILL corrupt an actual TiVo drive if it is connected to your PC when you boot Windows.

2a) If yes, then couldn't I use a NON-bootable HD formatted with a FAT32 partition on it for the backup file as opposed to having a bootable HD connected?
You should be able to write the file to any filesystem on any drive accessible (and mountable) from Linux. I believe that includes FAT32.

2c) If yes, could this disk be formatted using WIN 200/XP as a FAT32 partition?
I believe so. I don't recall how my Win98 drive is formatted, but it contains several Tivo backup images.

If you're using the MFS Tools CD-ROM, then you just need to make sure that you boot this CD rather than allowing the machine to boot Windows. You can set the BIOS to check the CD first before booting the hard drive, and thus you should be able to boot the system from the CD, even if your bootable Windows drive is still connected as C: and the Tivo drive(s) are connected to the other drive connectors. That way you can upgrade, backup, restore, etc. to/from the Windows drive without fear of corrupting the TiVo drive(s). Just make sure the system is booting properly from the (MFS Tools, etc.) CD (try it once, for example) before hooking up the Tivo drives and you should be fine...
--Steve

Robert S

12-21-2003, 01:37 PM

To get more swap you run mfsrestore with -s 150 (150Mb for 300Gb, for example - you need about 1/2000 of your disk space as swap). For values larger than 127, MFS Tools can not initialise the partition correctly, so you need to use mkswap or tpip to initialise the partition.

Any FAT32 partition is fine. You can put a small FAT partition on your 300Gb drive for the backup phase. You can use Drive Manager or FDISK+FORMAT as you prefer.

You should be able to mount your NTFS C: drive (you'll find it's read-only) if you wan to restore the backup to the 300Gb drive. You shouldn't have to have your live TiVo drive and a bootable WinXP drive connected at the same time.

DCIFRTHS

12-21-2003, 02:52 PM

After doing a "standard" upgrade using -s 150 and Lou's "PTVupgrade LBA48 MFStools 2.0 ISO" on my Pioneer 57H, I would use option three from your post here (http://www.tivocommunity.com/tivo-vb/showthread.php?postid=628229#post628229) ?

Since you say to boot using a TiVo boot CD, but NOT MFS Tools 2.0, would Lou's "PTVupgrade LBA48 MFStools 2.0 ISO" be okay?

Thanks.

Robert S

12-21-2003, 03:26 PM

You'd think so, but using the PC version of mkswap does not seem to work for the TiVo when creating new-style swap signatures. Todd compiled mkswap for the TiVo and people have used that to initialise their swap, but that's pretty fiddly and probably out of the question for a Series 2 TiVo.

Todd saved us from those hassles with tpip, which will initialise the swap partition correctly. (It will also copy the kernel on to the disk for you).

tpip is on the PTVU CD, so you might as well use that, but I think it has internal byteswapping (never actually used it myself), so any Linux boot disk should do. Lou introduced the CD here (http://www.tivocommunity.com/tivo-vb/showthread.php?s=&threadid=83342&pagenumber=21) and mentions there's documentation here (http://www.ptvupgrade.com/support/bigdisk/).

DCIFRTHS

12-21-2003, 10:26 PM

I missed this statement on Lou's page (every time I visited it):
Pioner DVR Series2 Units: This CD does not currently support creation of swap files greater than 127MB on drives built for Series2 Pioneer units. More information to follow.

I have been reading a lot the last few days because I really want to upgrade my 57H with a 300 GB disk. Unfortunately, I seem to be getting mixed opinions on increasing the swap and if it's even possible / necessary.

So what is the recommended upgrade procedure for large drives on the Pioneer? Is the additional swap a good idea?

tivoupgrade

01-06-2004, 02:46 PM

Originally posted by DCIFRTHS
I missed this statement on Lou's page (every time I visited it):

I have been reading a lot the last few days because I really want to upgrade my 57H with a 300 GB disk. Unfortunately, I seem to be getting mixed opinions on increasing the swap and if it's even possible / necessary.

So what is the recommended upgrade procedure for large drives on the Pioneer? Is the additional swap a good idea?

Using TPIP (included on the LBA48 CD we released) you can initialize a swap partition of any desired size. We've not been able to come up with a deterministic method for actually having a > 127GB swap FILE created within that partition. (I've been personally successful in doing it twice, but have been unable to replicate the initialization of the swap file consistently).

We don't believe its necessary to have the greater swap file sizes in order to have a successful and reliable upgrade -- we've been offering LBA48-enabled kits for TWO YEARS now and have had ZERO issues related to GSOD and non-recovery in any situation other than that of a defective drive. So, even though we now use large swap files wherever possible, mainly because some folks are concerned about it (IMHO, OVERLY CONCERNED), we would still encourage you to recommend upgrading even if you could not build a swap file greater than 127GB.

janol

02-17-2004, 05:20 PM

I've been reading this post for several hours now and it got me really worried.
I recently upgraded my Series 2 Tivo from single 40GB drive to 40+120 GB

I followed the famous instructions and used option #1 (without using -s 127 option) basically adding additional space to the 40GB drive. The instructions noted that I should be OK because my total capacity is less than 180GB.
My TiVo now reports 189Hrs of free space and I am worried that I did not expand the swap file.

What should I do??? Any help will be greatly appreciated.

Thanks,
Janol

Robert S

02-17-2004, 05:49 PM

1Gb=1.2 Hours.

janol

02-17-2004, 06:54 PM

I kind of figured it out, but the question is:

What should I do with my upgrade??
Should I be worried about the swap file problem? And if yes, what are my options?

Robert S

02-17-2004, 07:15 PM

You're OK for the moment. If you upgrade the A drive, consider increasing swap at that time. See the third post of this thread for a couple of ideas for dealing with insufficient swap.

You'll find it's a lot easier to increase swap on your first upgrade than to increase it later, but it's not necessarily a disaster if you don't increase it.

janol

02-17-2004, 09:13 PM

Thanks for all your help. I really appreciate you answering my questions.

As I understand, if -s 127 option was not used, 65MB swap file would be created. Would it be sufficient for 160GB of storage? Or should I rather do it now while I still do not have many things stored on my TiVo.

Is there any way to just increase the size of the swap file in my situation?

Again, thanks for all your help Robert

Robert S

02-17-2004, 10:25 PM

You seem to want me to keep repeating the same things. If you read the first few posts of this thread, I've tried to summarise our current thinking about how this works.

But, one more time, just for you: On a Series 2 TiVo you have 32Mb of RAM plus 64Mb of swap. This works out to be enough for just over 180Gb of disk space. 60+120Gb Series 2's have been seen recovering from GSOD's without extra swap.

There's no way to permanently increase swap without repeating the whole upgrade.

If you upgrade the A drive, that will take you over the limit and if your TiVo then GSOD'd, it would get stuck. When you upgrade the A drive you can manually create a larger swap partition before you expand the TiVo image to fill the larger drive. Or you can leave the swap alone and, in the unlikely event of a GSOD, temporarily expand the swap to allow the TiVo to recover.

Both those procedures are described in the third post of this thread.

kerkules

02-21-2004, 08:37 PM

Originally posted by Merle Corey
Ok, so I flubbed my guesstimate before. The magic number for getting fsfix to fail under -r 0 on a 40GB drive is 12MB of swap or less. 13MB works.

Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.

In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.

(Edit: Typo fix)

Useful trivia: If you have a TiVo that's greenscreen looping due to bad swapfile, but is otherwise of sufficient size, you can run mkswap -v0 /dev/hdX8 from the (byteswapped) boot disk and the TiVo will recognize the corrected swap, allowing fsfix to complete.

In other words, anyone who is up the creek because of having used -s 128...? It's fixable, without reimaging, even if the greenscreen loop has already begun.

Hi,

I have an SVR2000 with a 120+40 configuration that has been running for almost 2 years with no problems. Last week encountered the GSOD. It reboots several times then stays GSOD. Diagnostics on the drives have come out ok. How can I fix this? I don't have a backup image (it went down with my old computer).

I'm not very Linux-literate and was wondering how the "hdx8" part works with a dual drive system, (assuming my A Drive would be hda and the B drive is hdb). Thanks, K

Robert S

02-21-2004, 09:46 PM

If you don't have enough memory, the GSOD will reboot endlessly and with metronomic regularity. In that case, the techniques for initialising or increasing swap in the first few posts of this thread can save your TiVo.

The GSOD seems to reboot when it his a bad block, so irregular reboots suggest that the GSOD is allocating its RAM and getting to work, but there are lots of bad blocks on the disk.

The swap partition is on the A drive, so hdX8 needs to point to the A drive. If the A drive is primary master, then it's hda8.

If you can get the GSOD to resolve, you can make a new compressed backup. Otherwise you'll have to download one.

rtivo99

02-22-2004, 04:30 PM

As many people have pointed out. This thread is massive and I think I have confused myself.

I have a Series 2 SA that started out as a 40hr and I upgraded the drive A to a 120GB drive. I do not remember if I did the -s 127 switch or not.

What I would like to do is add a second 120GB drive as a B drive. How do I insure that I have enough swap space to avoid the GSOD reboot problem?

I am willing to perform the upgrade again from the current 120GB A drive to the new 120GB drive with the -s 127 switch if this is what is required. Then I could perform the mfsadd command. Am I on the right track?

Robert S

02-22-2004, 05:36 PM

There's nothing you can do now if you want to keep your recordings. All you can do is add the B drive. You can easily check whether you increased swap (you really weren't paying attention if you didn't!). When the PC boots, you'll see the partition table printed. If partition 7 (it's actually partition 8, of course, but it looks like 7) is 127Mb, then you're OK.

Even if you didn't, all you can do is hope you don't get a GSOD and if you do, use the 'rescue' from the third post of this thread.

TimTrace

05-14-2004, 10:25 AM

Robert -

This question regards a 2x160GB HDVR2, except for the HDD upgrade it is unhacked.

I've loaded my A drive into my PC, and booted with the MFSTools CD from http://mfstools.sourceforge.net .

PDISK shows #8 at 127.0M .

Am I safe, or have I missed something?

Thanks,

Tim ==

Willin

06-12-2004, 04:31 PM

Now that there aren't any software upgrades for S1 tivos, is there really a need to restore the inactive root partition? Why can't I leave it as a permanent swap?

I had 2 GSOD's within one week and it was a pain to do the recovery twice with the temporary swap partition.

Robert S

06-12-2004, 05:18 PM

Yes, you only have to restore the order of the partitions before the next software upgrade comes in.

I don't know what the effect of taking a software upgrade to the smaller root partition would be. It could be that the only way to recover would be to restore a backup, which is what the rescue was trying to avoid.

lbroadfield

07-06-2004, 03:23 AM

(First of all, thanks to Tiger, Robert S, Hinsdale, Dylan, etc. etc., without whom...)

OK, I'm running, but I goofed a little on the swap partition, and wondering if there's a way to un-goof.

I started with my 31201 which had previously (back in the days of BlessTiVo) had a 60GB "B" added to it's original 30GB "A".

Goal was to replace the original "A" with a new 120GB. I successfully dd'ed original-A to new-A, but I didn't quite grasp that I needed to follow the post#3 instructions to manually create the larger swap partition before using mfsadd to expand capacity.

Now I have a fully-expanded A with only a 64MB swap partition, and not enough room to create a new 128MB swap partition. Is there any way to ungoof this, or do I just to make sure to hang onto a copy of the rescue-via-inactive-root instructions forever?

(For extra credit, how do I ungoof it without losing recordings, or at least, losing a minimum of recordings?)

--Laird

Robert S

07-07-2004, 06:27 AM

I don't think you can reverse that without losing your recordings.

I would make the following observations:

GSOD's are pretty rare, so there's no real cause for worrying about it as long as the TiVo is working.

Software development for Series 1 TiVoes has ceased, so if you were to put it in the 'rescue' configuration, there's no urgent need to return it to its current configuration.

twash

07-07-2004, 10:08 AM

Objective: Add 160GB harddrive, as Drive B to a 112 and a 212 Phillips TiVo standalones, both of which already have working 120GB single drive upgrades, bought as plug and play from a couple of different sellers. These Phillips TiVos have been working successfully with the upgrade A drives for a couple of weeks now.

The A Drives are both Maxtor, the new drives are to be Samsung, 7200RPM, 160GB, because the Samsungs were the cheapest ones I found available at the time of purchase.

To fix them up I will install in my XP pc (yes, I know I am not supposed to boot to windows with the Tivo drives installed) with existing TiVo A drive plugged to Secondary Master IDE connector and the new drive B to the Primary Slave IDE connector. Said drives jumpered correctly as master and slave, respectively.

Since doing this increases the TiVo recording capacity to over 150GB, I read that I should do something to increase the swap file so the GSOD will still hopefully work, if called upon to do so. Apparently, I am to NOT DO the following command:

mfsadd -x /dev/hdc /dev/db

and am instead supposed to do a command that contains -s 127. My situation, adding a large B drive to an already existing 120GB, working, single drive Tivo, is not actually covered in the Hinsdale procedure, per say...well at least that is what appears to me to be the case.

Given my hookup can someone give me the correct command to use in lieu of the one above?

Another question, I don't plan on doing the backup image step since the full image already exists on each Drive A at this time. Am wondering just why this is a necessary step given my possession of two TiVo's. Can't I get it off the other Tivo if I lose one of the Drive A's at some point or is this image associated with the unit itself making it not transferrable to another unit?

Thanks in advance, ever so very much...

Robert S

07-07-2004, 01:44 PM

As the swap is on the A drive, there's not much you can do about it if you're just adding a B drive. (Well, you could, if you were prepared to do some serious hackage, but that shouldn't be necessary).

How did you create the current A drives? If you used mfsrestore with -s 127, then you already have enough swap for the new drives.

If you didn't increase swap when you created the A drives, then you're stuck now. All you can do is hope that you don't get a GSOD and, if you do, use the 'rescue' from the third post of this thread to recover.

As for backups, yes, you can use the image from the other TiVo.

twash

07-07-2004, 06:30 PM

Okay, I will try to find out from the guys I bought the upgrade A drives from to see if they used -s 127 and I will also save a copy of the post you refered to that says how to fix the problem if it occurs.

In the meantime, I will continue reading this thread, bout halfway through it now...should have read it long before I ordered those new drives...grin...oh well, that is part of the fun of this stuff, seeing if I can bail myself out of dumb you-know-what predicaments.

I guess that if (-s 127) was not utilized with those A drives, I could do the full procedure with restorable backup, etc, with the new drive as Drive A and the old drive as Drive B?

Robert S

07-07-2004, 07:31 PM

We've been telling people to use -s 127 for a couple of years now, so hopefully the drives already have 127Mb of swap.

TBH, I wouldn't go out of your way to fix it - the rescue works well enough.

You can check the swap yourself by booting in byteswapping mode and doing pdisk -l /dev/hdX

mitchsb

07-17-2004, 03:40 PM

I am trying to put in a new b drive into my tivo. I used the how-to guide provided, but when I do the mfsadd command, it says:

mfs_load_volume_header: mfsvol_read_data: Invalid argument
Unable to open MFS drives.

rkcarter

08-03-2004, 05:04 AM

I got an old computer for TiVo hacking. Trying to fix the GSOD problem. However, the CD drive on it is not bootable (it's an old Dell OptiPlex).

I start following instructions at the start of this thread -- but both the Dylan and the TivoMad floppies lack the "mkswap" utility. It's on the MFS Tools 2.0 floppy, but I don't see any obvious way to tell the MFS Tools 2.0 floppy to boot in byteswapped mode.

So... is there some way to get the mkswap utility off the MFS Tools 2.0 floppy running while I am booted in another of the boot disks, or some utility to add it to the other floppies or their RAM disk? I can't figure out how to mount another floppy with MFS Tools 2.0 up, nor the MFS Tools floppy with the other ones up, and even if so I imagine I'd need some way to uncompress the RAM disk.

I also have at my disposal a notebook PC so if there's anything I can do in WinXP (or booting from say the MFS Tools 2.0 CD) to make a floppy which would work, I can do it on there (where of course I can't mount the TiVo disks, this 2nd PC being a notebook PC and all).

Also, I suppose if I could mount the MFS Tools 2.0 CD while booted from one of the floppies that would work but I can't find a mount command that will work.

Thanks,

- Rick

Robert S

08-03-2004, 05:07 PM

CD doesn't mount? That's normally pretty painless. Remember CD's don't have partitions, so there's no digit in the device node.

mkswap is on the TiVo's hard drive, so you can just rewrite rc.sysinit to run mkswap when the TiVo boots.

I wrote up the procedure for my very first post on this site. I linked to it in the first post of the Fixes thread.

tfreitas

08-15-2004, 09:26 PM

Robert,
Great thread. I learned a lot. I've got an upgraded HDRV2 with a bad/clicking Maxtor. Previously upgraded with 120GB drive B - bad drive is original 40GB drive A. Bought a new Maxtor 80GB to replace the 40GB. Want to preserve recordings so I tried mfstools ddcopy - no luck. Then tried dd_rescue using knoppix. Got successful completion. Did mfsadd to expand and also got succesful completion. Booted in Tivo and got GSOD - recycling. Tried instructions from Post #3 of this thread - using dual disk instructions at bottom of post. I can not create a partition. Indicates "requested base and length is not within an existing free partition". Pdisk shows partition 16 "Apple_Free Extra" and a size of 3.1M. I'm trying to specify a swap partition of 128M. Am I out of space on this disk? Anything I can do to increase my swap partition? According to pdisk, my swap is 64MB, and a view of /mnt/var/log/messages shows 64MB as well. I'm hoping I'll be able to recover from GSOD if I can increase my swap size. But I'm stuck at this point.
Thanks for any help
Tim

Robert S

08-16-2004, 07:09 AM

You do that when you upgrade the A drive. After the copy but before the expand. Your A drive is already full.

You want to do the 'rescue' from the first part of that post.

tfreitas

08-17-2004, 09:00 PM

Robert,
Sorry to belabor this, but I think I'm close. I redid my dd_rescue and have not yet done the mfs_add. But I'm a bit confused. The first part of post #3 talks about determining the inactive root partition and making it a swap. Then it suggests that if you're upgrading a 2 drive Tivo, see details at end of post. The latter section talks only of adding a new swap partition - making it 128M. It doesn't talk at all about the inactive root partition. I do have a 2 drive Tivo - upgrading/replacing bad 40GB A drive with 80GB A drive while still preserving recordings on A and B drives(120Gb). Do I do just the latter section of post #3, or do I do the "boot in inactive partition" as well. I suspect I do only the latter part of post#3 but I'm about 30 hours in to this mess and am getting a little paranoid. Pdisk shows 13 partitions on my A drive. I tried creating 14p and it gave me "invalid partition" so I'm afraid I may have to do the laborious manual partition thing in post #7. Is that still my only choice? Thanks for any clarification.

Here's my partition table if that makes a difference ...
Partition map (with 512 byte blocks) on '/dev/hdd'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 1 @ 44023824
3: Image Kernel 1 8192 @ 44023825 ( 4.0M)
4: Ext2 Root 1 262144 @ 44032017 (128.0M)
5: Image Bootstrap 2 1 @ 44294161
6: Image Kernel 2 8192 @ 44294162 ( 4.0M)
7: Ext2 Root 2 262144 @ 44302354 (128.0M)
8: Swap Linux swap 131072 @ 44564498 ( 64.0M)
9: Ext2 /var 262144 @ 44695570 (128.0M)
10: MFS MFS application region 1048576 @ 44957714 (512.0M)
11: MFS MFS media region 32988398 @ 47054866 ( 15.7G)
12: MFS MFS application region 2 1048576 @ 46006290 (512.0M)
13: MFS MFS media region 2 44023760 @ 64 ( 21.0G)

Tim