TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Underground Playground > TiVo Upgrade Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 04-25-2014, 05:47 AM   #1
eboydog
Just TiVo'ing.....
 
eboydog's Avatar
 
Join Date: Mar 2006
Posts: 904
Roamio 4Tb Drive Development Thread

Is anyone working on DIY 4tb drive upgrade and is it worth starting a new thread here ? I must say that after having 3tb of storage in my Roamio, it's somewhat overwhelming and I do see having 4tb of storage as being unmanageable. I would like to figure this out simply as a challenge to overcome but in a practical day to day operation, having that much recording storage is crazy!

I'm not a hex editor type but with the recent thoughts of the image copy distribution of the drive that came up, I have an idea I would like to throw out to perhaps get things started in a legit manner rather than just copying someone else's work. Can't tell me that there are only one or two people on the Internet (other than Tivo themselves) that can figure this out!

My out of the blue idea: Has anyone done a sector copy of stock Roamio drive and then applied it to a 4tb drive? I plowed though the big Roamio drive upgrade thread and saw what happens when you put a raw 4tb drive in and the box tries to format it but rejects it but, what would happen if the basic unreadable image of a stock drive was written to the beginning of a 4tb drive, could that possibly overcome that initial rejection? I'm curious what something like Clonzilla could do.... It's my thought that perhaps there is no partition on the Roamio drive and when the box boots up, it looks for the drive and reads raw data off the drive at the beginning of the drive which contains "is this good" drive and if so the OS continues the boot and initialization process until everything is loaded. This is just my thought as unless I'm wrong, all conventional attempts to read the partitions in the conventional manner has failed, there must be a completely new and different file/data structure in place which would indicate a raw, most likely encrypted, data being written to the drive in a Stream like process.

Another issue which I mention in another thread which is a possible clue, those who have the 4tb drive solution are offering it for each Roamio model, their drive kits they offer don't appear to be a universal solution but each prepared drive only works in the model the buyer intends to install the prepared drive in. DVR Dude is very explicit in his eBay description that his kits can't be installed in a different Roamio model than specified. That implies there is some basic required identifying information on the drive that is required to start a successful identification process when the Roamio boots up. If the drive imaging process of a stock drive doesn't work, is there a utility that can read the raw sector data on a drive, save it and then rewrite such to another drive? Again I'm not describing using one of these prepared drives to accomplish this but to use a initialized stock drive to prepare a 4tb drive.

I have a extra basic Roamio and I'm pretty sure I going to buy a 4tb drive and start experimenting, in the worse case I can use the 4tb drive for other purposes if it doesn't work out but I'm hoping others might chime in and offer practical ideas. I'm willing to start something with providing the basic hardware and time, however I need assistance from some of you more knowledgeable TiVo hard drive gurus.

What do you think?
__________________
TiVo Roamio Pro
TiVo Roamio Plus (3tb)
TiVo Mini (three)
TiVo Premiere

eboydog is offline   Reply With Quote
Old 04-25-2014, 08:27 AM   #2
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
If you clone a Roamio drive to a 4TB drive it should work, but it won't use any of the extra space. Given the limitations of the 32-bit partition table the trick is to resize the first physical MFS media partition (#13) and move everything else around so that the second physical media partition (#11) starts just short of the 2TB limit. Then you resize that partition to use the rest of the available space.

Resizing MFS partitions is new ground. In the past you just added a "blank" partition to the end but that won't work past 2TB.

I'm working on a program to copy and expand any TiVo to its max, but it's months away.
ggieseke is offline   Reply With Quote
Old 04-25-2014, 09:53 AM   #3
eboydog
Just TiVo'ing.....
 
eboydog's Avatar
 
Join Date: Mar 2006
Posts: 904
OK, I had the misunderstanding that there was some mystery "ghost like" partition on the drives that no known utility or OS could read or manipulate.

The lack of discussion I thought was unusual but I guess most TiVo users are happy with 3tb.
__________________
TiVo Roamio Pro
TiVo Roamio Plus (3tb)
TiVo Mini (three)
TiVo Premiere

eboydog is offline   Reply With Quote
Old 04-25-2014, 11:44 AM   #4
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
Roamios use slightly different structures for the partition maps, MFS headers and zone maps than earlier models but they're still recognizeable. The main reason that existing programs like jmfs don't recognize it as a TiVo drive at all is that they switched the byte order.

It's just a matter of time. I know what I want to write and (mostly) how to do it, but I'm swamped at work right now.
ggieseke is offline   Reply With Quote
Old 04-25-2014, 01:48 PM   #5
unitron
Registered User
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,721
Quote:
Originally Posted by ggieseke View Post
Roamios use slightly different structures for the partition maps, MFS headers and zone maps than earlier models but they're still recognizeable. The main reason that existing programs like jmfs don't recognize it as a TiVo drive at all is that they switched the byte order.

It's just a matter of time. I know what I want to write and (mostly) how to do it, but I'm swamped at work right now.
When you say "switched the byte order", are we talking about Series 1 type byte swapping to accommodate the CPU?
unitron is offline   Reply With Quote
Old 04-26-2014, 08:30 AM   #6
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
Series 1s just swapped every pair of bytes in the sector something like this:

01 23 45 67 89 AB CD EF...
23 01 67 45 AB 89 EF CD...

You had to read everything in sector size chunks and 'swab' them before you could start to interpret the results.

Roamios use Intel byte order (least significant byte first) in Block0, the APM and MFS data structures instead of the Motorola byte order (MSB first) used by all earlier models. For 2 byte values like the Block0 signature it looks the same as a Series 1 and 14 92 becomes 92 14. Four byte fields like the partition start and size in the APM are completely reversed and you read them right to left. The same goes for 8 byte fields in some of the MFS header structures. For instance, the signature field for a 64-bit MFS volume header is 0xEBBAFEED. In a hex editor it looks like this:

EB BA FE ED (Series 2-4)
ED FE BA EB (Roamio)
ggieseke is offline   Reply With Quote
Old 04-26-2014, 09:23 PM   #7
unitron
Registered User
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,721
Quote:
Originally Posted by ggieseke View Post
Series 1s just swapped every pair of bytes in the sector something like this:

01 23 45 67 89 AB CD EF...
23 01 67 45 AB 89 EF CD...

You had to read everything in sector size chunks and 'swab' them before you could start to interpret the results.

Roamios use Intel byte order (least significant byte first) in Block0, the APM and MFS data structures instead of the Motorola byte order (MSB first) used by all earlier models. For 2 byte values like the Block0 signature it looks the same as a Series 1 and 14 92 becomes 92 14. Four byte fields like the partition start and size in the APM are completely reversed and you read them right to left. The same goes for 8 byte fields in some of the MFS header structures. For instance, the signature field for a 64-bit MFS volume header is 0xEBBAFEED. In a hex editor it looks like this:

EB BA FE ED (Series 2-4)
ED FE BA EB (Roamio)

But is the change to accommodate the CPU, like the S1s, or for some other reason?
unitron is offline   Reply With Quote
Old 04-27-2014, 08:11 AM   #8
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
I suspect that the new Broadcom chips use LSB first, but I don't have any hard data on them.

On Series 1s, I think that the byte swapping may have been inherent in the I/O circuitry. Even back then there were more 32-bit fields in the various headers than 16-bit fields, so matching it to the CPU doesn't really make much sense. It also made a complete hash of string values, requiring even more code for the CPU to run unless it was somehow handled on a lower level.
ggieseke is offline   Reply With Quote
Old 05-09-2014, 09:17 PM   #9
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
Mips chips are generally endiness flexible, but determined by the board designer. It is odd Tivo chose to make a switch at this point, but it might make sense if their hardware designs are coming from 3rd parties and the industry standard was LSB.

I'm thinking of the Cisco, Samsung, Mini and Stream boxes here which predate the Roamio release. And the Broadcom reference platforms.

I spent a couple nights looking into this 4TB issue.

My initial inclination is that there's a bug in the MFS creation code, so expect this is something Tivo will fix at some point. Has someone tried switching to a 4TB drive after the box was updated to 20.4?

Aside from MFS, the rest looks straightforward to me. One thing that would help down the road is the Roamio linux kernel. Maybe this deserves it's own thread but Tivo has fallen significantly behind in posting it's GPL and OSS code base.

Someone want to go ask them for it?

PS. Is there any reference / good thread on MFS data structures? I couldn't find any beyond generalities.
__________________
Premiere 2 tuner & SiliconDust
on Comcast CableCard + OTA
telemark is offline   Reply With Quote
Old 05-09-2014, 09:44 PM   #10
unitron
Registered User
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,721
Quote:
Originally Posted by telemark View Post
...

PS. Is there any reference / good thread on MFS data structures? I couldn't find any beyond generalities.
Yes, they come as part of the TiVo service manual package.


Unfortunately, that gets delivered by Unicorn Express.
unitron is offline   Reply With Quote
Old 05-10-2014, 02:09 PM   #11
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
I'm getting from a hard drive + hex editor:
Code:
Series 5: feed ebba 
Series 4: baeb edfe
Edit: and that would be because I'm in word mode instead of byte mode. Nevermind.

Last edited by telemark : 06-07-2014 at 07:19 AM.
telemark is offline   Reply With Quote
Old 05-10-2014, 06:01 PM   #12
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
Here is a link to the newer software. https://www.tivo.com/legal/opensource It has version 2.0 and 2.1 OS for the premiere and 1.0 for the stream.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-10-2014, 06:08 PM   #13
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
Yah, I looked through that and everything else I could find. I believe there are no Roamio era releases in anything on the Tivo website.

I'd be happier to be wrong here.

The reason I conclude that summarily is the Roamio logs indicate the kernel is Linux 3.3.8, and all the sources I could find on Tivo.com were 2.something.

It might still be useful to someone.

There is a program called pdisk64 for example. Has a number of interesting comments. I myself didn't see how to get it built, nor could I tell if it was bi- until it was built. Real C programmers could probably do it, cause I think I was just short 1 include for 1 function call which is probably part of the OS.

Last edited by telemark : 05-10-2014 at 07:01 PM.
telemark is offline   Reply With Quote
Old 05-10-2014, 08:01 PM   #14
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
The Premiere OS version number on the site I do not believe corresponds to the Linux version. I am wondering though if 2.0 stands for OS 20.x.x. I haven't spent time looking through it to determine if that is the case. It just that there was an OS 19.x.x and the Web site has a version 1.9. So it leads me to think so. But I have not confirmed that in any way.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-11-2014, 08:57 AM   #15
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
I doubt that the Linux kernel would do us much good anyway since it's all in flash memory on a Roamio and the open source code that they do release has nothing to do with MFS.
ggieseke is offline   Reply With Quote
Old 05-11-2014, 10:58 AM   #16
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
That is true. Would help premieres more. The previous open source releases had some MFS building and checking tools.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-23-2014, 07:27 PM   #17
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
I'm at the point that my next step would be to make a test release.

This would a 4TB whole disk image with large chunks of zero-ed data.

I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.

Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.

Last edited by telemark : 05-23-2014 at 07:44 PM.
telemark is offline   Reply With Quote
Old 05-23-2014, 10:51 PM   #18
eboydog
Just TiVo'ing.....
 
eboydog's Avatar
 
Join Date: Mar 2006
Posts: 904
Quote:
Originally Posted by telemark View Post
I'm at the point that my next step would be to make a test release.

This would a 4TB whole disk image with large chunks of zero-ed data.

I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.

Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.
So there is no way to exclude.the.zero padded part ?

myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.can you.offer any details.in what.you.did.to allow it to recognize.the 4tb drive?
__________________
TiVo Roamio Pro
TiVo Roamio Plus (3tb)
TiVo Mini (three)
TiVo Premiere

eboydog is offline   Reply With Quote
Old 05-24-2014, 01:20 AM   #19
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
> So there is no way to exclude.the.zero padded part ?

I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.

> myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.

Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].

My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.

> details.

forthcoming, after I'm done building and testing (then documenting).
telemark is offline   Reply With Quote
Old 05-24-2014, 03:03 AM   #20
nooneuknow
TiVo User Since 2007
 
Join Date: Feb 2011
Location: Cox Cable Market, NV
Posts: 3,117
Quote:
Originally Posted by telemark View Post
> So there is no way to exclude.the.zero padded part ?

I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.

> myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.

Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].

My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.

> details.

forthcoming, after I'm done building and testing (then documenting).
It's worth adding that large, contiguous, blocks of zeroed sectors compress down VERY well, with most compression utilities.

I can compress (zip) down a virgin 2TB .VHD TiVo image file to 1.5GB, or less, and nothing is left out when it is restored, either as a quick restore, or writing all data, including the zeroes (nothing left to chance). The quick restore takes about 2 minutes, at most. The full restore takes as long as writing all zeroes to to whole drive using drive testing tools.
__________________
Cisco tuning adapters should never be used inline (using the TA coax OUT port) to connect a TiVo, if MoCA is in use. Use a splitter w/PoE filter on leg to TA, use other leg for the TiVo. Enjoy!
nooneuknow is offline   Reply With Quote
Old 05-24-2014, 08:03 AM   #21
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
Quote:
Originally Posted by telemark View Post
> So there is no way to exclude.the.zero padded part ?

I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.

> myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.

Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].

My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.

> details.

forthcoming, after I'm done building and testing (then documenting).

How are you developing the image? Are you using a Roamio self built image and modding that to get a working 4TB image, building one completely from scratch, or using a 3rd party image and modding that?
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-24-2014, 09:18 AM   #22
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
Quote:
Originally Posted by telemark View Post
I'm at the point that my next step would be to make a test release.

This would a 4TB whole disk image with large chunks of zero-ed data.

I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.

Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.
dd and gzip should be fine. In windows 7z can read gzip files and I believe a program from HDDGuru can read the dd files and write them to a drive.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-24-2014, 09:53 AM   #23
nooneuknow
TiVo User Since 2007
 
Join Date: Feb 2011
Location: Cox Cable Market, NV
Posts: 3,117
Quote:
Originally Posted by jmbach View Post
dd and gzip should be fine. In windows 7z can read gzip files and I believe a program from HDDGuru can read the dd files and write them to a drive.
HDDGuru's HDD Raw Copy Tool can do .VHD files. I just fired it up and didn't find any options besides drive to drive, VHD to drive, and drive to VHD.

Since .VHD files have that 2TB limit, I'm not sure if it will be of much help here.

I was quite surprised that I overlooked that raw Windows utility for my planned 3TB to 3TB Roamio drive clone (from WD Red NAS to WD AV-GP). Hopefully it won't object to >2TB on a drive-to-drive, and has better speed that GNU dd rescue (what jmfs uses).

I'm wondering if there's a reason that utility never comes up when people ask about, or provide answers about, cloning TiVo drives. Raw is raw, so it should work (theoretically). I'll post again after I try it out.
__________________
Cisco tuning adapters should never be used inline (using the TA coax OUT port) to connect a TiVo, if MoCA is in use. Use a splitter w/PoE filter on leg to TA, use other leg for the TiVo. Enjoy!
nooneuknow is offline   Reply With Quote
Old 05-24-2014, 10:41 AM   #24
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
The HDD Raw Copy Tool saves images with an img extension, which if I remember correctly, I had dd copy back to a drive. At least it used to. My version is several years old. It also can save an image in a compressed format it labels as a dimg.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-24-2014, 11:02 AM   #25
nooneuknow
TiVo User Since 2007
 
Join Date: Feb 2011
Location: Cox Cable Market, NV
Posts: 3,117
Quote:
Originally Posted by jmbach View Post
The HDD Raw Copy Tool saves images with an img extension, which if I remember correctly, I had dd copy back to a drive. At least it used to. My version is several years old. It also can save an image in a compressed format it labels as a dimg.
The most recent version, which is several years old, works with Windows 7, surprisingly. I haven't tried it with 8/8.1 yet.

Upon further scrutiny, I found it does read raw drives, .vhd files as if they were drives, and can write them to .img and .imgc files. I don't have any of those .img or .imgc files to see if it can read from them to write them to a drive with the program.

I suppose if I created a new blank VHD and had it mounted, the program should be able to write to it.

I've never used dd for disk to file, or file to disk, so I can't comment on what currently will work and what won't, with those file types.
__________________
Cisco tuning adapters should never be used inline (using the TA coax OUT port) to connect a TiVo, if MoCA is in use. Use a splitter w/PoE filter on leg to TA, use other leg for the TiVo. Enjoy!
nooneuknow is offline   Reply With Quote
Old 05-25-2014, 05:44 PM   #26
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
> Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

It turns out it would have been easier for me to strip 0's, but it would have been harder to reconstitute, so it's the same situation.

In any case, I have a Linux installer uploaded. Waiting for hash confirmations now. Feel free to PM me if you want to be the first test subject, until I get the documentation ready. Ideally with access to Linux and a Base Roamio.

> It's worth adding that large, contiguous, blocks of zeroed sectors compress down VERY well, with most compression utilities.

Ya, I got 1,000:1 and 640,000:1

> How are you developing the image? Are you using a Roamio self built image and modding that to get a working 4TB image, building one completely from scratch, or using a 3rd party image and modding that?

In-between option 1 and option 2, approximately.

I haven't seen anyone else's images besides what my Roamio would build to avoid taint, though, having gone through this exercise, I'd be curious to hear of anything they chose differently as I spent extra effort to make what I thought were the best attributes to have.

Last edited by telemark : 05-25-2014 at 05:52 PM.
telemark is offline   Reply With Quote
Old 05-26-2014, 12:28 AM   #27
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 836
How much recording space did you end up with?
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is offline   Reply With Quote
Old 05-26-2014, 06:17 AM   #28
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
So here's the story. If you put a 4TB drive in a Roamio and leave it to format, the logs shows a crash here:

Formatting MFS partitions (/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13)
/dev/sda has [sectors in 512] blocks
Disk size >= 128 gibibytes (268435456 blocks), using big MFS extents
Disk size >= 140 gibibytes (293601280 blocks), using 64-bit MFS format
Creating 500000 inodes, please wait
assert: Tmk Assertion Failure:
assert: HPK_Result TivoDiskIOGetBlockSize(HPK_DiskIOInstance*, HPK_UInt32*), line 115 ()
Process fsmake([PID]) killed by signal Unknown signal -2--2
Tmk Fatal Error: Thread fsmake <[PID]> strayed!
Paste the following into a shell to get a backtrace...
bt -t /tvbin/tivoapp <<END_OF_BT
[stuff]
END_OF_BT

And summarily reboots itself.

What this implies is the drive is left with the MFS filesystem never formatted (and whatever else comes after that).

Whether that's a bug vs reasonable check, and whether it will eventually be changed, I can see being debatable.

The conclusions from this though, if you keep that value within an Unsigned Int 32bits, the format would have succeeded. Or if you properly finish the MFS format offline (and what remains of the installation), in any of variety of ways, the drive would be accepted.

Also relevant, after the default partitioning for 4TB, the kernel recognizes / reports this partition list:
sda: [tivo] sda1 sda2! sda3! sda4! sda5! sda6! sda7! sda8! sda9! sda10! sda11![M] sda12! sda13![M] sda14! :)

I'm under the assumptions:
- the '!' is used to designate a 64bit format record in the partition table.

The kernel source would contain the exact definition of each symbol.

Edit: This is under 20.3.6, the first OS this box came with.

Last edited by telemark : 05-26-2014 at 02:29 PM.
telemark is offline   Reply With Quote
Old 05-26-2014, 07:30 AM   #29
telemark
Registered User
 
Join Date: Nov 2013
Posts: 814
So one cheap and quick method, is set a HPA, but I seriously hope nobody ever runs that way.

My preferred method is:
1) build a partition map by hand
-everything within 32bits
-centered, with the MFS media partitions equal
2) MFS format offline, using whatever combination of tools / hardware
(I know this is the interesting part, but I can not redistribute all the software, and some of the hardware is rare, so I'd rather skip over the details)
3) Check every other partition is set sanely.
4) Confirm the installation continues.

> How much recording space did you end up with?
I didn't tweak the other partition sizes, the media partitions come to:
3900923680 * 2 * 512 bytes = 3.6TB

Last edited by telemark : 05-26-2014 at 08:16 AM.
telemark is offline   Reply With Quote
Old 05-26-2014, 11:41 AM   #30
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,049
Yeah, it lays out the partition table on a 4TB drive using some 64-bit APM entries, but something else in the autobuild process doesn't recognize it and it's bootloop time.

I haven't seen anyone get the 64-bit APM working on a primary drive yet, but the Weaknees 4TB external does use it.

I haven't actually tried 20.4.1 yet but I don't expect TiVo to fix it until they start selling 4TB Roamios.
ggieseke is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 09:44 PM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |