Is there an easier way to do this (without getting a third drive)?

[sstormont]

I have a DSR7000 that came with a 40GB drive.

A number of months ago, I added a 200GB drive using "UPGRADE CONFIGURATION #1 (From: Any Single Drive TiVo, To: Adding a New B Drive)" from the Hinsdale guide.

I just recently the LBA48 aware kernel.

TivoWebPlus reports:

Filesystem Type Size
/dev/hda4 ext2 124M
/dev/hda9 ext2 124M

But it says that I still only have 157 hours of recording time.

Is the only way to access the extra 60GB that I wasn't using before the LBA48 kernel upgrade (and to save my recordings) is to buy a new 200GB drive (or larger) and then follow "UPGRADE CONFIGURATION #4: From: Any Dual Drive TiVo, To: New A or New B Drive (replacing only one or the other))" correct?

There is no way to just expand to access the extra 60GB that is now recognized after the kernel upgrade, correct? (there has to be a copy involved somehwere in order for the partition to be expanded to fill the disk, right?)

[ocntscha]

Actually I think its quite possible getting that extra 60Gig might be a piece of cake but I'm requesting more information:

Hopefully your Tivo has the pdisk command on it. Can you either telnet into it or use the "Enter shell command" option of the Hackman module in TWP if you have that and just give the command..

pdisk -l /dev/hda /dev/hdb

and paste the output here so we can have a look at your current partition tables.

[sstormont]

pdisk -l /dev/hda /dev/hdb

Partition map (with 512 byte blocks) on '/dev/hda'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 4096 @ 77261888 ( 2.0M)
3: Image Kernel 1 4096 @ 77265984 ( 2.0M)
4: Ext2 Root 1 262144 @ 77270080 (128.0M)
5: Image Bootstrap 2 1 @ 77532224
6: Image Kernel 2 8192 @ 77532225 ( 4.0M)
7: Ext2 Root 2 262144 @ 77540417 (128.0M)
8: Swap Linux swap 131072 @ 77802561 ( 64.0M)
9: Ext2 /var 262144 @ 77933633 (128.0M)
10: MFS MFS application region 1048576 @ 78195777 (512.0M)
11: MFS MFS media region 33100800 @ 44161088 ( 15.8G)
12: MFS Second MFS application region 1048576 @ 79244353 (512.0M)
13: MFS Second MFS media region 44161024 @ 64 ( 21.1G)
14: Apple_Free Extra 319 @ 80292929


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 7103 @ 268428352 ( 3.5M)

bash-2.02#

[ocntscha]

Ok, and as I understand it /dev/hdb is actually a 200 Gig drive and now that your Tivo has an LBA48 aware kernel you want it start using the additional space.

Lets see what the experts here have to say but my conjecture is you should be able to

pop BOTH drives out of your Tivo

put them in a PC, for example at postions A drive at secondary master, B drive at secondary slave

Boot from an LBA48 aware CD like the PTVupgrade cd and just issue the command

mfsadd -x /dev/hdc /dev/hdd

done.

Put the drives back in the Tivo and enjoy the extra space.

[sstormont]

You are correct; I have a 200GB drive and now after installing the LBA48 kernel, want to take advantage of the extra space without losing any recordings or buying another drive.

Will hopefully wait for some more replies then I'll give your command a shot.

[sstormont]

Stuck both drives in a PC (A drive at secondary master, B drive at secondary slave)

Booted from PTVupgrade cd and issued the command

mfsadd -x /dev/hdc /dev/hdd

Screen then said:

Current estimated standalone size is 196 hours.
Nothing to add!

However, when I go to System Information on the Tivo and look at the "Recording Capacity" section, it says "Variable, up to 157 hours"

[ocntscha]

Hmm, bummer.

Thats a pretty big discrepancy in the hours too. Even so though, my guess is that the Tivo and mfsadd are both "seeing" the same amount of space 40 + 137 and probably use a little different formula to determine the hours.

Really what you just did "should" work according the mfstools README file..

The simplest and most useful method of running mfsadd, assuming the TiVo
A drive is the secondary master and there is no B drive, is:

mfstool mfsadd /dev/hdc -x

Or if there is a new B drive connected to the secondary slave as well:

mfstool mfsadd /dev/hdc /dev/hdd -x

The first command will fill the extra space on the A drive, creating new
partitions as needed. It will be able to do this even if the partition
table does not reflect the true size of the drive, as would be the case
after a drive to drive copy with "dd". The second command will do the same,
and will also create partitions on the B drive. If the B drive is also a
copy of an existing TiVo drive, it will add new partitions.
I highlighted the part I did because its the situation you have, your partition table does not reflect the true size of your drive.

Now according to this (http://www.tivocommunity.com/tivo-vb/showthread.php?p=629559&highlight=pdisk+mfsadd#post629559) post mfstools can sometimes have a problem with that situation and say there is nothing to add and the solution is outlined to make the partition table accurate for your drive.

I recently had a more less identical situation to what you have now, I replaced only my B drive by dd'ing it to a much larger one and then successfully used mfsadd -x /dev/hdc /dev/hdd like you are attempting now. However, I didn't even try it without first making the partition table accurate for the newer larger drive. I just followed the excellent directions in that post I just linked to.

The other question I'd have for you though, and I'm not even sure if this would matter or not - Can your PC's BIOS utilize more than 137Gig of a drive? If you have a fairly new PC it should and as I said, I'm not even sure it matters, I think maybe even if you have an old PC that can't deal with large drives in and of itself its not really going to matter as far as an LBA48 aware Linux being able to use an entire drive on that old PC. I don't know. I'm guessing there's a person or two on here who do know, maybe they'll chime in. In my case, I actually was using a pretty new make of a PC that could natively deal with large hard drives.

Bottom line, I guess what I'm saying is, if you have a new PC, if you just follow the procedure in that post I linked to make your partition table accurate for the size of your drive and then do the mfsadd -x /dev/hdc /dev/hdd I still think it has an excellent chance of working. If you have an older PC then you may or may not even be able to make a partition table that uses the whole drive.

Another possibility is too, if you just did what you did on an older PC, you may be able to successfully do the same thing on a newer PC and not have to mess with the partition table if you don't want.

I'm going to end this post like this - Where are all you experts?? 2 questions I have for you experts 1) does the discrepancy he's seeing in his hours seem out of line? If so can you explain it? 2) can an old PC that can't natively use large hard drives still work with them OK using an LBA48 aware Linux?

[sstormont]

The PC that I used is a newer PC that does see the full 200GB size.

[ocntscha]

Well since you have a PC that can see the full drive thats the same situation I had and it worked for me. But I did follow the directions in that post I linked to above to recreate a partition table that reflects the true size of the drive before I did the mfsadd -x /dev/hdc /dev/hdd.

It probably sounds scary recreating the partition table, it did to me. But those are some very excellent instructions and it actually turned out to be a quite easy procedure once I just jumped in and did it. I doubt it even took me 10 minutes.

I still think if you just redo the partition table on your B drive so that it reflects the true size of your drive, then do the mfsadd -x /dev/hdc /dev/hdd it will work. At least according to the documentation it should work and it did work in my case. I instantly got all my additional space and all my recordings remained intact.

[tivo4mevo]

1) does the discrepancy he's seeing in his hours seem out of line? If so can you explain it? 2) can an old PC that can't natively use large hard drives still work with them OK using an LBA48 aware Linux?

I'm no expert, but

1) I think that discrepancy (between what the System information page and what MFSTools 2.0 reports) is about right. From memory, I know that the number of hours reported in the System Information page is always less than the number of GB (i.e., my 160GB drive reports ~147 hours or something like that). I can't recall how MFSTools reported it, but I can find out. If MFSTools were to estimate a bit on the high side, then the discrepancy seems reasonable to me.

2) (this may not matter as the OP's PC BIOS detected the full size of the drive, but) his old PC, once booted to a Linux boot CD running an LBA48 aware kernel can properly use a large hard drive, even if the BIOS couldn't detect the correct size of the drive.

The PC's BIOS affects how far it into the drive the BIOS can address; this typically only becomes an issue when a PC's BIOS tries to boot a partition that is beyond its limit (hence the old "8GB limit" and others that caused so much headache for multi-booting systems). Once the BIOS has successfully handed off execution to a valid boot partition, the kernel in that OS determines the addressing limits.

On Tivo's, folks get into trouble when they have a system correctly using a custom LBA48 kernel, and then an upgrade installs a stock kernel that is not LBA48 aware. When that happens, the MFS pointers point to areas of the disk the kernel can't address, and shows start to get corrupted. I think it can be even worse other partitions (root, var) or critical MFS database lie beyond 137GB, then the system may not even fully boot.

[ocntscha]

2) (this may not matter as the OP's PC BIOS detected the full size of the drive, but) his old PC, once booted to a Linux boot CD running an LBA48 aware kernel can properly use a large hard drive, even if the BIOS couldn't detect the correct size of the drive.
Thanks for weighing in. I kind of thought that was the case but wasn't really sure, never tried it. Thanks for confirming. As you say though, its kind of a moot point anyway since the OP's computer does see the entire drive.

Good info regarding the size discrepancy too.

Thanks.

[sstormont]

I'm no expert, but

1) I think that discrepancy (between what the System information page and what MFSTools 2.0 reports) is about right. From memory, I know that the number of hours reported in the System Information page is always less than the number of GB (i.e., my 160GB drive reports ~147 hours or something like that). I can't recall how MFSTools reported it, but I can find out. If MFSTools were to estimate a bit on the high side, then the discrepancy seems reasonable to me.

Before I installed the LBA48 BIOS, System Information reported 157 hours. So even with the discrepancy between MFSTools and System Information, both numbers should have increased after the new kernel (and 60GB of wasted space) was made available?

[tivo4mevo]

Before I installed the LBA48 BIOS, System Information reported 157 hours. So even with the discrepancy between MFSTools and System Information, both numbers should have increased after the new kernel (and 60GB of wasted space) was made available?

You're correct that if you successfully increased your MFS partitions to fill the entire 200GB disk (/dev/hdb), your unit should report more than 157 hours. But there is more at work than just replacing your the unit's kernel . You need to update (expand) your second hard drive to create new MFS partitions that will utilize that extra ~60GB of space.

It's possible you may be using an old MFSTools Boot CD, a boot CD that itself is not lba48 aware, and this is what's causing your headache. This has been covered in the forums, so search a bit for posts like this (http://dealdatabase.com/forum/showthread.php?t=44659&highlight=expand+mfsadd+lba48)

But in short, you should
1) verify you have a new MFSTools boot CD (4.01 and higher should work) that has an lba48 kernel on it.
2) boot to that CD and attempt your mfsadd again.
3) failing that, MFSTools may be getting fooled by your foreshortened Apple Free patition, and thus you should follow the directions for fixing the partition map that ocntscha linked to in his post (and finally attempt your mfsadd one more time).

[sstormont]

I used the "PTVupgrade LBA48 boot CD" which says that it has MFSTools 2.0 on it and is LBA48 aware.

[ocntscha]

Right sstormont, if your not using an LBA48 boot CD that would explain why the mfsadd didn't work for you.

Here's a link to the free CD that ought to work for you..

http://www.ptvupgrade.com/products/software/lba48/lba_4.02_license.html

I totally agree with what Tivo4mevo just posted. His "in the short" steps 1,2,3 sound dead on to me. I've just took care of 1 for you. Let us know how steps 2 and/or 3 go.

[sstormont]

Your link is to version 4.02. I used version 4.04 from the same site:

http://downloads.ptvupgrade.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=LBA48DD&Category_Code=

[ocntscha]

Your link is to version 4.02. I used version 4.04 from the same site:

http://downloads.ptvupgrade.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=LBA48DD&Category_Code=

Oh well, that rules that out. Proceed to step 3.

[Narf54321]

sstormont, since your box is already hacked, try downloading alldeadhomiez' tivopart archive (http://www.dealdatabase.com/forum/showthread.php?t=25219). It includes lba48chk for several platforms (PPC and MIPS Tivo, plus an x86 Linux version).

lba48chk.mips will help show whether the Tivo can "see" all of the 200GB drive.
(You can also use lba48chk.x86 to see if your boot CD on the PC is LBA48 aware).

[sstormont]

I think I fixed it:

I started by following the steps listed here that were listed by ocntscha:

http://www.tivocommunity.com/tivo-vb/showthread.php?p=629559&highlight=pdisk+mfsadd#post629559

I wasn't able to use the Kazymyr Boot CD as it told me that my hdb did not have a partition table.

I booted using the PTVUpgrade version 4.04 CD instead and followed the steps listed in the link above.

When I did all of that, I then tried to run:

mfsadd -x /dev/hda /dev/hdb

Which returned:

Current estimated standalone size is 196 hours.
Adding pair /dev/hdb4-/dev/hdb5
New estimated standalone size is 271 hours.
Estimated standalone gain is 75 hours.

I figured that something is up since the amount of hours can never exceed the size of the installed drives, correct?

I then wiped the partition table again, recreateed partitions 2-3, and did not perform the mfsadd command. Now when I boot the unit, System Information reports 213 hours which sounds about right and the partition table now looks like:

Partition map (with 512 byte blocks) on '/dev/hda'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 4096 @ 77261888 ( 2.0M)
3: Image Kernel 1 4096 @ 77265984 ( 2.0M)
4: Ext2 Root 1 262144 @ 77270080 (128.0M)
5: Image Bootstrap 2 1 @ 77532224
6: Image Kernel 2 8192 @ 77532225 ( 4.0M)
7: Ext2 Root 2 262144 @ 77540417 (128.0M)
8: Swap Linux swap 131072 @ 77802561 ( 64.0M)
9: Ext2 /var 262144 @ 77933633 (128.0M)
10: MFS MFS application region 1048576 @ 78195777 (512.0M)
11: MFS MFS media region 33100800 @ 44161088 ( 15.8G)
12: MFS Second MFS application region 1048576 @ 79244353 (512.0M)
13: MFS Second MFS media region 44161024 @ 64 ( 21.1G)
14: Apple_Free Extra 319 @ 80292929


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 122293616 @ 268428352 ( 58.3G)

I'm guessing all is well and I really don't need to run the mfsadd command?

[eastwind]

Current estimated standalone size is 196 hours.
Adding pair /dev/hdb4-/dev/hdb5
New estimated standalone size is 271 hours.
Estimated standalone gain is 75 hours.

I figured that something is up since the amount of hours can never exceed the size of the installed drives, correct?

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 122293616 @ 268428352 ( 58.3G)

I'm guessing all is well and I really don't need to run the mfsadd command?
You'll need to run it if you want access to that 58.3G at the end of the drive.

Why can't the hours exceed the size of the drives? There's no overhead on the second drive (root, boot and var partitions), so you get to use more of it. Besides, mfstools is only an estimate--and only for SA TiVos (maybe SAS1s). What does the DTiVo think?

ew

[ocntscha]

I booted using the PTVUpgrade version 4.04 CD instead and followed the steps listed in the link above.

When I did all of that, I then tried to run:

mfsadd -x /dev/hda /dev/hdb

Which returned:

Current estimated standalone size is 196 hours.
Adding pair /dev/hdb4-/dev/hdb5
New estimated standalone size is 271 hours.
Estimated standalone gain is 75 hours.
Good job my man, sounds like you did it. Your adding 58Gig or or 63Gig or somewhere there abouts depending if your talking in powers of 2 or 10. 75 hours sounds like a reasonable estimate for mfstools to have made for that amount of space, particulary since as we learned from tivo4mevo, its basing its estimate on the amount of space used by the Standalone models which is less Megabytes per hour than the Directivos. Success. Put the drives in the Tivo done.
I figured that something is up since the amount of hours can never exceed the size of the installed drives, correct?

I then wiped the partition table again, recreateed partitions 2-3, and did not perform the mfsadd command.No, no, no, no!! Arrggh!! Its like your victory dance was to pull out a shotgun and start blasting away at your feet. Man I don't know what kind of state its in now or what you can do. When you went in and recreated the original partition table again, did you happen to make note of the boundaries for partitions 4 and 5 that mfsadd had made? If so, I would think you ought to get that second drive back in your PC, recreate the whole partition table again including partitions 4 and 5, then not run mfsadd, just put it back in your Tivo and hope for the best. If you don't know what the boundaries where for 4 and 5 then I guess there's really nothing you can do except carry on and hope for the best. I don't know, I don't know how mfs works, maybe it'll be able to carry on fine even though you wiped out the partition entries. Actually as I'm typing this and thinking about my guess is that it probably will be ok. Maybe someone who does understand MFS can come on here and state if your OK or not. Ahh geez. I'd about given up on you, when we hadn't heard from you for a few days I thought we'd scared you off. Glad you had the courage to try it. Hopefully it was a success. Hopefully you haven't just demonstrated for us the meaning of "fixin' it 'til its broke".

[sstormont]

When you went in and recreated the original partition table again, did you happen to make note of the boundaries for partitions 4 and 5 that mfsadd had made? If so, I would think you ought to get that second drive back in your PC, recreate the whole partition table again including partitions 4 and 5, then not run mfsadd, just put it back in your Tivo and hope for the best. If you don't know what the boundaries where for 4 and 5 then I guess there's really nothing you can do except carry on and hope for the best.

There were only 4 partitions to begin with on the 200GB drive:

#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 7103 @ 268428352 ( 3.5M)

I then recreated partition 2 and 3 so that I then had:

#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 122293616 @ 268428352 ( 58.3G)

With the configuration like this, the TIVO reports in the "System Information" that there are 213 hours (didn't check what mfs thought at this point).

It was when I ran the "mfsadd -x /dev/hda /dev/hdb" command that mfs created a partition 4, 5, and 6 in addition to the partitions 2 and 3 that I made and told me that I had 271 hours. I never actually booted the TIVO when the 6 partitions were in existence since sum of the size of each partition appeared to be larger than the size of my drive. Since that didn't look right, I deleted the partition table and only created the initial 4 partitions that were listed.

The 240GB kit listed here:

http://www.newreleasesvideo.com/hinsdale-how-to/upgradeservice.html

Says that it provides for 230 hours on a DirecTIVO which is why I thought that the 271 hour number was wrong.

[tivo4mevo]

sstormont,

I think you were confused by the differenet hour estimations given by MFSTools and by the DTiVo software. Given you have a combined size of 240GB, the 271 reported by MFSTools sounds appropriate (remember, MFSTools is reporting in SA Tivo hours) and the 213 hours reported by your unit's system information screen sounds about right for the DTiVo software.

The problem is that now your unit believes that it has two extra MFS partitions (the extra ~60GB on your hdb) at its disposal; however, when it goes to access them, it may or may not work correctly as those partitions aren't reflected in hdb's partition map. I fear that your unit may appear to run fine for a while, but then might crash, going into a green screen when it finally attempts to write a recording to that partition.

I'm at a loss as to the best way for you to proceed at this point. I'm not sure if you should try mfsinfo, kickstart a MFS filesystem check on the unit, try to recreate hdb's partition map, or try to run mfsadd again. Since your unit seems to power-up, I would disconnect the sat feeds, powere it up, and pull any shows that you can't live without!


mfsinfo might give you feel for whether or not the MFS database info in your primary MFS partition set is borked or not, though I'm not sure it it can correct it or not.

Kickstarting an MFS filesystem check might be the safest, though I'm not sure what action it will take when it encounters the missing partitions. I think it would take none, as the filesystem fix is a different kickstart code, so this might be the safest route.

As ocntscha recommended, your could recreate the 4th and 5th partitions on hdb, provided that you still have the information about the location and length of the partitions.

I'm not sure what effect running mfstools -x (add) would have (it would probably recreate hdb partitions 4 & 5 in the same manner as before, but I'm not sure what affect that would have on the MFS database info in your primary MFS partition set.


If I were in your shoes, I would probably try mfsinfo first, and if it indicates an error, I might then try to recreate hdb's partition map. If you don't have the original partition layout, then you might try to use the following partition map. PLEASE NOTE THAT DOING THIS MAY FURTHER DAMAGE/BREAK YOUR UNIT.

That said... assuming that mfsadd would have set up a slim MFS application partition, that would be 1024 blocks, and assuming that you didn't specify the partition scale parameter (-r [0-4]) while doing the add, then the MFS media partition would have fallen along 1MB blocks, that would yield an hdb partition table that would look like this:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122292224 @ 268429376 ( 58.3G)
6: Apple_Free Extra 368 @ 390721600

Again, note that this partition map is based upon my conjecture, based upon my limited knowledge, based upon what you've written. If you choose to create this partition map, I would suggest running mfsinfo afterwards to see if there are any CRC errors, then you might try reading the out the first few blocks of both partitions 4 & 5 (using dd and then a hex editor) and comparing them to partitions 2 & 3. If they look somewhat similar in structure, then that might comfirm the map to be correct. Even if that looks good, kickstarting an MFS filesystem check would still probably be a good idea (to prevent a GSoD later on down the line).

Jamie may be able to comment more, as he knows a bit more about the MFS FS structure (as evidenced by his AO perl script to coalesce MFS partitions).

[sstormont]

The problem is that now your unit believes that it has two extra MFS partitions (the extra ~60GB on your hdb) at its disposal; however, when it goes to access them, it may or may not work correctly as those partitions aren't reflected in hdb's partition map.

What two extra partitions does it think that it has? This is the partition table after I used pdisk to recreate partitions 2 and 3. Partition 4 correctly lists the extra 58 GB that I wasn't able to get before the LBA48 BIOS



#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 122293616 @ 268428352 ( 58.3G)



This is what the original table looked like:



#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: Apple_Free Extra 7103 @ 268428352 ( 3.5M)



So the recommendation to "recreate the 4th and 5th partitions on hdb, provided that you still have the information about the location and length of the partitions." was in regards to the hdb4 and hdb5 partitions that the mfsadd command made since there were only 4 partitions on the original drive to begin with, correct?

I did not specify any extra parameters when I ran the mfsadd command.

[ocntscha]

Your Tivo thinks it has the mfs partitions 4 and 5 that where created when you ran the mfsadd command.

When you ran the mfsadd command not only did it create those partitions but it also modified the mfs database or something somewhere anyway on the A disk I would imagine which "tells" your Tivo that its now got those partitions 4 and 5 available to it on the second disk. The problem is that because of that your Tivo now "thinks" it has those partitions available to it, which is why it now tells you the capacity is 213 hours, but the reality is those partitions aren't actually there anymore because you went back and removed them.

Does that make sense? In other words even though you deleted those new partitions your Tivo "thinks" they are there.

We're afraid you haven't seen a problem yet because your Tivo hasn't actually had need to use those non-existant partitions yet but we're afraid as soon as it does decide it wants to save a recording onto the new partitions it thinks it has but doesnt you might be in for a world of hurt.

I would suggest that you shut down your Tivo completely while its still functioning, cross your fingers and hope Jamie will weigh in with a comment and/or suggestion.

[tivo4mevo]

So the recommendation to "recreate the 4th and 5th partitions on hdb, provided that you still have the information about the location and length of the partitions." was in regards to the hdb4 and hdb5 partitions that the mfsadd command made since there were only 4 partitions on the original drive to begin with, correct?

Correct. Disk hdb should end up with six partitions (including the Apple_Free Extra partition).

I did not specify any extra parameters when I ran the mfsadd command.

Then my guess at the partition map might be correct. Running mfsinfo before and after trying to restore the partition map might provide you with confidence that my map is correct.

[sstormont]

So at this point, I should put both drives in a PC and then run:

mfsinfo /dev/hda /dev/hdb

Then use pdisk to recreate the table on hdb as follows:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122292224 @ 268429376 ( 58.3G)
6: Apple_Free Extra 368 @ 390721600


Then run "mfsinfo /dev/hda /dev/hdb" again and it should report 271 hours and I don't need to run mfsadd or do anything else, correct?

Or should I kickstart it and run 57 or 58 first?

[tivo4mevo]

I would go the mfsinfo route first. If mfsinfo reports errors before you fiddle with the part map, but not afterwards, then you have some degree of confidence that you're on the right track.

Then you could do a fscheck kickstart (which may take a while).

[eastwind]

dd if=/dev/hda10 bs=1 count=256If you put this command in at bash prompt while in the TiVo, it will show you the current partition set that the mfs will be looking for. If it doesn't list /dev/hdb4 and /dev/hdb5, your current partition table will be fine. (If you use the command while your TiVo's "a" drive is in a PC, substitute the appropriate drive letter.)

ew

P.S. mfs_info will also show this information along with a lot more. The info will be in the device list.

[sstormont]

I just connected to the TIVO via Telnet and typed


dd if=/dev/hdb10 bs=1 count=256


And it returned:


0+0 records in
0+0 records out


I tried running "dd if=/dev/hda10 bs=1 count=256" on hda10 and got:


«ºþí³�¹’ 
@  À H¥Ô/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdb2 /dev/hdb3 /dev/hdb4 /dev/hdb5 Ô ¡
è
*� é x a 
  * Ž j
N" € 256+0 records in
256+0 records out


Running mfs_info /dev/hda /dev/hdb returned this:


WARNING: total sectors doesn't match (total=470080512 sb=470078464)
Super:
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdb2 /dev/hdb3 /dev/hdb4 /dev/hdb5
zonemap_ptr=1121 total_secs=470078464 next_fsid=106
backup_zonemap_ptr=ffffe zonemap_size=1
/dev/hda10 has 1048576 sectors
/dev/hda11 has 33100800 sectors
/dev/hda12 has 1048576 sectors
/dev/hda13 has 44161024 sectors
/dev/hdb2 has 1024 sectors
/dev/hdb3 has 268427264 sectors
/dev/hdb4 has 122293248 sectors
/dev/hdb5 has 0 sectors
zone(0):
sector=1121 type=0 start=1122 next_zonemap=525410
size=524288 per_chunk=524288 limit=525410 zone_size=524288
backup_sector=ffffe zonemap_size=1
backup_next_zonemap=ffff5 next_zonemap_size=9
buddy_size=1
zone(1):
sector=525410 type=2 start=1048576 next_zonemap=525419
size=33099776 per_chunk=2048 limit=34148352 zone_size=33099776
backup_sector=ffff5 zonemap_size=9
backup_next_zonemap=fffd3 next_zonemap_size=34
buddy_size=15
zone(2):
sector=525419 type=1 start=525453 next_zonemap=34149376
size=523072 per_chunk=8 limit=1048525 zone_size=523072
backup_sector=fffd3 zonemap_size=34
backup_next_zonemap=21913ff next_zonemap_size=1
buddy_size=17
zone(3):
sector=34149376 type=0 start=34149377 next_zonemap=34673665
size=524288 per_chunk=524288 limit=34673665 zone_size=524288
backup_sector=21913ff zonemap_size=1
backup_next_zonemap=21913ed next_zonemap_size=18
buddy_size=1
zone(4):
sector=34673665 type=2 start=35197952 next_zonemap=34673683
size=44161024 per_chunk=2048 limit=79358976 zone_size=44161024
backup_sector=21913ed zonemap_size=18
backup_next_zonemap=21913cb next_zonemap_size=34
buddy_size=16
zone(5):
sector=34673683 type=1 start=34673717 next_zonemap=79358977
size=524176 per_chunk=8 limit=35197893 zone_size=524176
backup_sector=21913cb zonemap_size=34
backup_next_zonemap=4baefee next_zonemap_size=17
buddy_size=17
zone(6):
sector=79358977 type=2 start=79360000 next_zonemap=347787265
size=268427264 per_chunk=8192 limit=347787264 zone_size=268427264
backup_sector=4baefee zonemap_size=17
backup_next_zonemap=14bad3f6 next_zonemap_size=9
buddy_size=16
zone(7):
sector=347787265 type=2 start=347788288 next_zonemap=0
size=122290176 per_chunk=8192 limit=470078464 zone_size=122290176
backup_sector=14bad3f6 zonemap_size=9
backup_next_zonemap=deadbeef next_zonemap_size=0
buddy_size=15
total_inodes: 524288

id=0 type=8/tyDb hash=0 sec=1122 typexx=0 units=0 size=8 runs=0
fsid 0 is a total of 8 bytes


What next? Rebuild the partition table as specified by tivo4mevo? Or do some of the numbers above conflict with the numbers in that suggestion? Can't imagine running the steps above from a boot CD with the drives out of the TIVO would return any different results, right?

[ocntscha]

What next? Rebuild the partition table as specified by tivo4mevo? Or do some of the numbers above conflict with the numbers in that suggestion? Can't imagine running the steps above from a boot CD with the drives out of the TIVO would return any different results, right?That confirms what we where telling you, you're Tivo "thinks" it has mfs partitions hdb4 and hdb5 available to it. That's great that you got us that information, we should be able to use that to reconstruct your partition table, we'll find out if tivo4mevo's educated guesstimation was accurate or not but what you need to do right now is shut the thing off before its to late. And as far as your other question, no I wouldn't expect to get any different results from what you've just posted using an mfstools boot cd.

[ocntscha]

/dev/hdb2 has 1024 sectors
/dev/hdb3 has 268427264 sectors
/dev/hdb4 has 122293248 sectors
/dev/hdb5 has 0 sectorsHmm, hmm. Well it thinks it has hdb4 and hdb5 but I think I mis-spoke when I said we'd be able to use this information to reconstruct what it was like right after you did the mfsadd. I hadn't looked at it closely yet and now that I have the above doesn't look to good to me. I don't know sstormont, probably you'd be ok if you went with Tivo4mevo's educated guesstimation of what your partition map looked like right after you did the mfsadd, he seems to really know what he's talking about. But, I'd give it some more time if I where you and see what anyone else might contribute to this thread before you run off and make any more changes.

So have we answered your original question yet? Isn't this an easier way to do it than getting a third drive?? ;)

[Jamie]

Wow, what a mess.

The tivo software globs together all the partitions in the device list into one big virtual address space. As it happens, the /dev/hdb4 that you deleted starts at the same sector as the new /dev/hdb4 Apple_Free Extra, so your drives are still usable. The new /dev/hdb4 is a bit longer than the old /dev/hdb4 and /hdb5 put together, so you get the "total sectors doesn't match (total=470080512 sb=470078464)" warning.

You've basically stubbled your way into a sloppy partition coallesce (http://alt.org/forum/index.php?t=msg&th=124&start=0&rid=0&S=1e914fde117feb7d9b13c985a8bc3982#msg_num_3). It seems that the tivo software doesn't mind the minor inconsistency in the total sector count. The "Apple_Free Extra" partition on your B drive isn't really free space; it's now part of your MFS. That could cause grief downstream if you ever try to expand again or manipulate the partition table. You should probably reconstruct a valid partition table for your B drive.

I believe all the information you need is here to reconstruct the proper partition table. You'll want to add appropriately sized hdb4 and hdb5 partitions. You'll want 2048 left over sectors in the new hdb6 Apple_Free extra. That's the difference between total and sb in the warning above. I don't think it matters where the break is between hdb4 and hdb5.

[sstormont]

To reconstruct the table on the drive, would it be your opinion to go with:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122292224 @ 268429376 ( 58.3G)
6: Apple_Free Extra 368 @ 390721600


as posted earlier?

I would create partitions 2-5 and not 6, correct?

Then, should I or should I not run mfsadd -x /dev/hda /dev/hdb

[ocntscha]

To reconstruct the table on the drive, would it be your opinion to go with:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122292224 @ 268429376 ( 58.3G)
6: Apple_Free Extra 368 @ 390721600


as posted earlier?

I would create partitions 2-5 and not 6, correct?

Then, should I or should I not run mfsadd -x /dev/hda /dev/hdbNope, I finally just had a chance to read Jamie's post carefully, he's right we can do this and the above is not what you want. Patience. I'll work out what I think it should be, stay tuned..

[Jamie]

I'd suggest you don't change anything until you are able to answer these questions yourself. Post your answers and we'll check your understanding.

[ocntscha]

I'd suggest you don't change anything until you are able to answer these questions yourself. Post your answers and we'll check your understanding.Ahh, Jamie. Well I just spent some time sitting here with pen, paper, and calculator, and have it all worked out for him. I was about to post it just now when I spied your message. Hmm, hmm, hmm. Oh I don't know, should we just let him twist in the wind?? Seem a little bit cruel, but ok, I'm game.

[sstormont]

I'd suggest you don't change anything until you are able to answer these questions yourself. Post your answers and we'll check your understanding.

Make a partition map that looks like:

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 201649088 @ 268429376 ( 58.3G)
6: Apple_Free Extra 2048 @ 470078464

And do not run mfsadd -x /dev/hda /dev/hdb after making the table?

[sstormont]

I'd suggest you don't change anything until you are able to answer these questions yourself. Post your answers and we'll check your understanding.

Scratch the above. I meant:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 122293248 @ 268428352
5: MFS New MFS Media 79356864 @ 390721600 ( 58.3G)
6: Apple_Free Extra 2048 @ 470078464

[Jamie]

Ahh, Jamie. Well I just spent some time sitting here with pen, paper, and calculator, and have it all worked out for him. I was about to post it just now when I spied your message. Hmm, hmm, hmm. Oh I don't know, should we just let him twist in the wind?? Seem a little bit cruel, but ok, I'm game.I don't mean to be cruel, but taking a stab at figuring it out seem like it is more valuable and more like to lead to success than following instructions that are not fully understood.

Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
...
5: MFS New MFS Media 201649088 @ 268429376 ( 58.3G)
...
Partition 5 looks too large to me. 201648088 512 byte sectors adds up to something like 100GB.

[sstormont]

Is my updated partition 5 correct?


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 122293248 @ 268428352
5: MFS New MFS Media 79356864 @ 390721600 ( 58.3G)
6: Apple_Free Extra 2048 @ 470078464

[Jamie]

Is my updated partition 5 correct?


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 122293248 @ 268428352
5: MFS New MFS Media 79356864 @ 390721600 ( 58.3G)
6: Apple_Free Extra 2048 @ 470078464
Still doesn't look right to me. If I'm reading your earlier partition table right, you have a 200GB disk with 390721968 512 byte sectors on it. Your partition 5 and 6 above will both run off the end of the drive.

You know what size you want partition 4 to be (1024 sectors) and where it must begin (right after partition 3). Likewise, you know what size you want for the Apple_Free Extra partition (2048) and where it must *end* (the last sector on the disk). From this you should be able to derive the starting sector and size of partition 5.

[sstormont]

It is a 200GB drive, but I thought that it had 470078464 sectors based on the mfs_info output.

Using 390721968, I came up with:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122290544 @ 268429376 ( 58.3G)
6: Apple_Free Extra 2048 @ 390719920

[Jamie]

It is a 200GB drive, but I thought that it had 470078464 sectors based on the mfs_info output.mfs_info is telling you the total size of all the MFS partitions (including the A disk).Using 390721968, I came up with:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122290544 @ 268429376 ( 58.3G)
6: Apple_Free Extra 2048 @ 390719920
Looks right to me. ocntscha?

[sstormont]

mfs_info is telling you the total size of all the MFS partitions (including the A disk).Looks right to me. ocntscha?

And I am correct that I don't need to run "mfsadd -x /dev/hda /dev/hdb" since they have already been added to MFS, right?

[ocntscha]

Scratch the above. I meant:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 122293248 @ 268428352
5: MFS New MFS Media 79356864 @ 390721600 ( 58.3G)
6: Apple_Free Extra 2048 @ 470078464

No, you where closer the first time. I'll give you some hints.. according to Jamie where the boundary between 4 and 5 is doesn't matter. The Mfstools README file basically says the same thing, it says if you are creating a pair just make a big and a small one. I don't think I've ever seen an example online or in my own experience though where the first of an MFS partion pair wasn't 1024 blocks. So if it where me, I'd stick with the accepted norm and make partition 4 1024 blocks. I see you've picked up on Jamie's hand out that partition 6, the free space needs to be 2048 bytes. So, there you go, there's 2 of of the 3 partition sizes.

[Jamie]

And I am correct that I don't need to run "mfsadd -x /dev/hda /dev/hdb" since they have already been added to MFS, right?Right. Wouldn't hurt if you did; it should say "nothing to add" or something similar.

[ocntscha]

Using 390721968, I came up with:


Partition map (with 512 byte blocks) on '/dev/hdb'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS New MFS Application 1024 @ 64
3: MFS New MFS Media 268427264 @ 1088 (128.0G)
4: MFS New MFS Application 1024 @ 268428352
5: MFS New MFS Media 122290544 @ 268429376 ( 58.3G)
6: Apple_Free Extra 2048 @ 390719920

Yep, that is absolutely identical to what I came up with ealier when I worked it out on paper.

Edit.. except for the (58.3G) note on partition 5. I didn't even bother with that as pdisk will calculate that all by itself, it'll come out somewhere around there, 58.2, 58.3 whatever pdisk says will be right.

[sstormont]

I created the new partition table as specified and mfs_info no longer reports any errors. Thanks again for all the help!

When I ran mfsinfo, it said that the drives could be expanded 2 more times and that I had 271 hours capacity.

When I put the drives back in the TIVO and booted it, "System Information" still says 213 hours.

SHould I run the mfsadd -x command just to make sure that it says there is nothing to add, or are the 213 hour vs 271 hour numbers correct? The 271 hours reported by MFSTools is in SA Tivo hours where as the 213 hours reported by System Information is not for a standalone unit, right?

[ocntscha]

I created the new partition table as specified and mfs_info no longer reports any errors. Thanks again for all the help!

When I ran mfsinfo, it said that the drives could be expanded 2 more times and that I had 271 hours capacity.

When I put the drives back in the TIVO and booted it, "System Information" still says 213 hours.

SHould I run the mfsadd -x command just to make sure that it says there is nothing to add, or are the 213 hour vs 271 hour numbers correct?If it'll make you feel better run the mfsadd -x command. I guarantee you it will say there's nothing to add. Get over the 213 vs. 271 hour numbers, its ok. Everything's fine man. Its all done and its all right. You did it!

[sstormont]

I just wanted to make sure that I was getting the most out of these drives, since after the fun I had this time, I don't think I'll be going back into the box for a while.

I ran mfsadd and it did indeed say that there was nothing to add.

I was just confused since the Hinsdale 240GB upgrade kit I saw listed ~230 hours for DirecTivo. I guess that the since it says approximately 230 hours, that could include the 213 hours, but I just wanted to make sure I was using all that I could.

Thank you all so very much for your help!