[dmprantz]

Series 1 DTiVo, stock 40GB drive plus a 60GB drive, 100GB total. After 4 years of this setup, it appears that one of the drives is going bad: Picture and sound distortion every 10-30 seconds, only on one of two units coming from the same multiswitch, and it survives past a reboot...so....

I bought a 250GB drive on the cheap, and the plan is to "fix" the going bad drive and upgrade space at the same time. Plan to use a current boot CD with MFSTools 2.x (or whatever is current) to copy and expand the volumes. Didn't see a FAQ, but I've been away for a while, and if some one could point me to one or answer the following questions, I'd be much appreciative:

1) Where would I get a current boot CD image? The one I have only has MFSTools 1.1 on it. Was doing manual additions of volumes back then.

2) What can I do to support the full 250GB? Does the current S1 software support it out of the box, or do I need to hack it? I'm not interested in kernel hacking for this, cause then I'll have to repatch it for an update, not what I want to do!

3) To resize the swap partition or not? I was thinking of maxing it out to 512M, but will this still cause problems? What's the largest "safe" size?

4) Anything else I should consider doing or be careful of?

tia,

dmp

 

[funtoupgrade]

I don't think the boot image is dependent on what version mfstools was used to create it, so I would go ahead and try it on just the new drive then test it and see if it looks ok. If all is well then you can reimage it along with whichever other drive you will be using to come up with your final configuration. Everytime you image a drive it completely erases everything there so you can feel free to play around and not hurt anything.

You will need to upgrade the kernel if you are going to use mfstools 2.0 with LBA48 support. This is one more step only, and TiVo will not be updating any series one software. Just make sure that whatever software emerges from the restore is, in fact, the latest one. If not sure ask here on the forum after providing make and model of Tivo. If you do not use the LBA48 mfstools you will be limited to 137GB on your drive regardless of how big it is.

Rule of thumb for swap file size is half of the total disk sizes.

 

[classicsat]

1: Get one from PTVupgrade.

2:copy/expand as normal with the LBA48 CD, then use copykern to upgrade the system kernel.

3: 127 for an S1 I think. You are about the recommended swap size with that.

 

[dmprantz]

1: Get one from PTVupgrade.

2:copy/expand as normal with the LBA48 CD, then use copykern to upgrade the system kernel.

3: 127 for an S1 I think. You are about the recommended swap size with that.

Thanks for the info, I got the free CD from PTVUpgrade. I guess I'll do the LBA48 hack, but what is the latest version of the software. I'm at 3.1.0c. Looks like there may be a 3.1.1 version available? Do I need to contact DTV to force a download of that?

dmp

 

[dmprantz]

Well, I decided to start with the copy in case there wasn't an update, and to make sure I had a good version in case the update killed the disks. Ran into a problem, one that Classicat seems to know some about, and I'm not sure on an easy way to fix it.

A little background. Before when I said that this TiVo was a little over 4 years old, I was wrong. I have realized that this was actually my original DTiVo, which was one of the originals bought in November, 2000. Those units came with two drives, a 30 and a 15. Later, when I wanted to upgrade it, I did some work. I had a 40 from another TiVo, and I wanted to add a 60. Since the stock config had 45GB, it wouldn't fit on the 40, and I had to move both original pairs to the 60. I did this manually and edited the MFS superblock to point to /dev/hda in stead of /dev/hdb for the second pair. I then manually added a third pair to that A drive, and then blessed the 40 and manually added it, so there are four pairs total. When I say manually, I mean with a hex editor. I was quite proud of it at the time (before MFSTools 2.0) and I was able to expand a dual drive system without losing any space or recordings.

Now, it appears that MFSTool will not let me put all of those partitions on one disk. The PM is 63 sectors long, and isn't each PM entry one sector in size? I have 15, so I should be able to put a total 48 more on there. Does linux still have problems with drives that have > 15 partitions on them?

So far, it looks like I have a few options:

1) Shrink the volume set down and lose all of my recordings....not likely!

2) Find a way to force MFSTool to expand the PM beyond 15 entries....Again, I don't see that as likely.

3) Find a way to automatically combine multiple pairs into a single pair. I can't find any tools that do that, and I've forgotten so much about mfs, I don't trust myself enough to write one in a timely manner anymore.

4) Use dd to in stead of MFSTool to do this. That will get the first three pairs over. Then create /dev/hda16 and /dev/hda17 to be the exact same sizes, then dd the old /dev/hdb partitions over those. Then go back and replace/repair the superblocks so that the fourth pair is /dev/hda in stead of /dev/hdb. Something I don't like about this, using dd could hit a bad block and lock the drive, while mfstool doesn't hit every block. Another issue, mfstool then won't allow me to add a fifth pair. I'll have to go back to manually adding it I think Is there a safer way to do this?

5) I saw a reference once that said I could combine most all of the partitions (4-8 in MFS land) into a single partition. Just create a partition that has the right number of sectors dd everything over with the right offsets, and then modify the superblock appropriately. I could do this, but it would mean losing two 4MB app regions. I don't think this will cause a problem, but I'd have to inspect the zone map to be sure they aren't used. Will MFSTool let me add a third pair, or does it draw a line at 13 partitions?

Any options that I missed?

Thanks!

dmp

 

[classicsat]

You have two real options. Either lose recordings, or merge partitions, which you will manually do.

You cannot have more than 16 partitions, that is the absolute limit of the partition system.

I would not try to make system partitions into mfs partitions.

 

[dmprantz]

Thanks for the info. I'm doing the dd copy now. Hopefully won't be too painful. I dunno what you mean by making system partitions MFS partitions. Obviously I don't wanna try to make partitions 1-9 MFS, but the MFS media regions will need to be included in an MFS application region for this to work. I doubt that there are any database or iNode zones in those 8 MB.

Why do you say that you cannot have more than 16 partitions? That is not an Apple Partition Map limitation. The Apple PM really has no maximum size, and was designed to be that way. The PM itself is dynamic and can allow as many or as few partitions as you want. Just to prove it, I went out and added 4 extra partitions to my big disk (19 total), pdisk didn't complain at all. I read some where that there is a 63 partition limit for IDE drives, but I'm no where near that. I also read that at one time linux had a problem with > 15 partitions on one HDD, but you say 16, and I wouldn't be surprised if that was fixed by now. Is this a TiVo limitation? I doubt it, since the MFS limit is 12, on two (four?) disks plus the 9 standard, giving 21. As far as I can tell, this is only an MFSTools limit. Can you point me towards a reference that explains why there is this 16 partition limit? Thanks.

dmp

 

[dmprantz]

Well, I'll be my own reference, or yours, or something like that. To test it out, after I copied all 17 partitions onto the A Drive and edited the MFS Superblock, I put it in the TiVo, and watched it reboot repeatedly. Looking at the logs, it appeared that this is a limitation in the TiVo software, devices stored in an array type data structure that only has enough room for partitions up to /dev/hda16. I dunno if it's 7 MFS partitions or 16 partitions total, but the result is that no more than 16 partitions on the A-Drive can exist due to TiVo's C++ code

The good news though is that my upgrade worked. I recreated the A drive partition layout in pdisk and dd'ed each A Drive partition over individually. I did it this way so that I could increase the size of /dev/hda8 (Swap), and also because one of my partitions was not a good size. It has to be on a 512k barrior for the logical partition, and I had to truncate it down so that the combined partition would work. I figured the easiest way was to create a smaller partition and let dd burp when it reached the end. After that, I was able to delete and recreate partitions in pdisk, modify the MFS superblock, and she booted right up! I took it from 8 MFS partitions down to 4, and then used MFSTools to add two more. I now have 250 GB and lost no recordings.

While I was doing this, I had another idea on how to do this, and it goes back to Tiger's original A-Drive expansion hack: DD all the partitions over by hand, and then recreate the device files /dev/hdb2 and /dev/hdb3 to point to /dev/hda16 abd /dev/hda17, or some similar setup. Now linux will treat those partitions as if they were on seperate drives, and no repartitioning needed! Problems with this abound though: Still can't use MFSTools to perform copy. A future upgrade will trash this setup. Probably can't use MFSTools to expand the MFS device any more either. If you can create the partitions manually in pdisk and tell MFSTools to use that pair specifically, it may work, but if MFSTools insists on creating its own partitions, it will screw everything up when it attempts to access /dev/hdb. I wouldn't say this is a better approach, but maybe a little easier if you don't want to expand and don't want to do the math of shrinking down your existing partitions.

Thanks again!

dmp

 

[bnm81002]

Rule of thumb for swap file size is half of the total disk sizes.

what if I was replacing the original 40GB drive with a 300GB drive, should I use a swap file size of -150 or should -127 would be sufficient enough? thanks