TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Underground Playground > TiVo Upgrade Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 01-21-2013, 11:09 PM   #1
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
Premiere HD upgrade with jmfs failed

I tried to upgrade my Premiere HD from a 1T drive to a 2T drive and didn't quite get it right. I'm hoping for a suggestion here to keep from having to go back to an older hard drive.

The version of JMFS that I have been using is 1.04. Both drives are WD AV drives and the new one did not require the parking disabling.

I work with Windows PCs daily and know them fairly well. I know very little about Linux and that has limited my options.

I tried to be clever (my big error!) and used my hard disk duplicator to image the 1T to the 2T drive. My (erroneous) assumption was that I could do the Expand after that copy.

I was short of time (too many household members grumbling about TiVo being down), so I threw the 2T drive in the system after the imaging and figured I would do the Expand later. Another bad choice.

The 2T drive works just fine, but only has 1T total capacity. That's what I expected after the imaging.

Eventually, I removed the 2T drive and tried to do the Expand. The software said that it failed. The numbers that it gave for disk size made it clear that it was only looking at about 1T of disk space.

My next "clever" trick was to try to copy the 2T drive to a 1.5T drive that I had on hand (I didn't have a spare 2T). JMFS objected that the source drive was smaller than the source, but I told it to go ahead. I figured that the 2T drive was only partitioned out to 1T, so it should fit. The copy ended with an error (it ran out of space), but the 1.5T drive seemed to work fine in the TiVo. It booted just fine and I was able to retrieve a random assortment of recordings that I had.

I tried doing the Expand on the 1.5T and got the same sort of error as I did with the 2T drive. Just as a test, I tried running Supersize. It claimed to work without error, but Expand still wouldn't work. I put the 2T back in the TiVo.

As a test, I used JMFS to copy the original 1T drive to the 1.5T. It too 6-8 hours (?), but ended without error. I told it to do the Expand and it completed without error. I never tested this drive, but I am assuming that this process worked properly. If only I had not been "clever" with the disk imager originally!

So..... as I see it, I have two solutions if I want the 2T to work. One is to start over, copy from the 1T to my 2T, and lose the last month or two of recordings. (It has been that long since I started this process.) With my video provider (Frontier), it seems that nearly everything that I record is protected, so I can't just copy these programs over to my other TiVo.

My hope is that there is some clever person here who can tell me some commands to execute on the 2T drive that will allow it to Expand to use the full drive. (Yeah... and I hope to win the Lottery!)

I can recopy to the 1.5T and try any suggestions with little risk. If I can Expand the 1.5T from 1T to the full 1.5T then I would expect to have no problem copying it back to the 2T and expanding it there.

Thanks in advance to anyone who can offer constructive suggestions on this.
Oregonian is offline   Reply With Quote
Old 01-24-2013, 11:26 PM   #2
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Quote:
Originally Posted by Oregonian View Post
I tried to upgrade my Premiere HD from a 1T drive to a 2T drive and didn't quite get it right. I'm hoping for a suggestion here to keep from having to go back to an older hard drive.

The version of JMFS that I have been using is 1.04. Both drives are WD AV drives and the new one did not require the parking disabling.

I work with Windows PCs daily and know them fairly well. I know very little about Linux and that has limited my options.

I tried to be clever (my big error!) and used my hard disk duplicator to image the 1T to the 2T drive. My (erroneous) assumption was that I could do the Expand after that copy.

I was short of time (too many household members grumbling about TiVo being down), so I threw the 2T drive in the system after the imaging and figured I would do the Expand later. Another bad choice.

The 2T drive works just fine, but only has 1T total capacity. That's what I expected after the imaging.

Eventually, I removed the 2T drive and tried to do the Expand. The software said that it failed. The numbers that it gave for disk size made it clear that it was only looking at about 1T of disk space.

My next "clever" trick was to try to copy the 2T drive to a 1.5T drive that I had on hand (I didn't have a spare 2T). JMFS objected that the source drive was smaller than the source, but I told it to go ahead. I figured that the 2T drive was only partitioned out to 1T, so it should fit. The copy ended with an error (it ran out of space), but the 1.5T drive seemed to work fine in the TiVo. It booted just fine and I was able to retrieve a random assortment of recordings that I had.

I tried doing the Expand on the 1.5T and got the same sort of error as I did with the 2T drive. Just as a test, I tried running Supersize. It claimed to work without error, but Expand still wouldn't work. I put the 2T back in the TiVo.

As a test, I used JMFS to copy the original 1T drive to the 1.5T. It too 6-8 hours (?), but ended without error. I told it to do the Expand and it completed without error. I never tested this drive, but I am assuming that this process worked properly. If only I had not been "clever" with the disk imager originally!

So..... as I see it, I have two solutions if I want the 2T to work. One is to start over, copy from the 1T to my 2T, and lose the last month or two of recordings. (It has been that long since I started this process.) With my video provider (Frontier), it seems that nearly everything that I record is protected, so I can't just copy these programs over to my other TiVo.

My hope is that there is some clever person here who can tell me some commands to execute on the 2T drive that will allow it to Expand to use the full drive. (Yeah... and I hope to win the Lottery!)

I can recopy to the 1.5T and try any suggestions with little risk. If I can Expand the 1.5T from 1T to the full 1.5T then I would expect to have no problem copying it back to the 2T and expanding it there.

Thanks in advance to anyone who can offer constructive suggestions on this.
I think that when you used your disk duplicator it created a partition that fills up the disk so JMFS cannot expand. Run MFSLayout on the JMFS disk on your 2TB drive and post the results. You also might want to have a copy of the MFS Live CD handy because if that is the case, will have to use pdisk on the MFS Live CD to delete that partition then use JMFS to expand.

Jim
__________________
"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 01-25-2013, 06:56 PM   #3
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
The duplicator should have done a bit-for-bit copy with no interpretation of the data nor changes to partitions.
I will run MFSLayout soon and let you know what it says.

Thanks for the input!
Oregonian is offline   Reply With Quote
Old 01-26-2013, 12:03 AM   #4
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
I agree with you. Would not expect it to modify the partition table. I guess it could possibly copy not only the drive data bit for bit but also the drive architecture. I'm reaching now for an explanation. Back with the old drives before ide drives when the controller for the drive was in an adapter card you could modify the drive architecture. In any event MFSlayout will help determine what needs to be done next.

Sent from my SPH-L710 using Tapatalk 2
__________________
"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 01-26-2013, 06:32 AM   #5
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
What is a Premiere HD?

On the back of the TiVo there's a sticker with a model number that starts with TCD.

What is that number?

Did you mean a Premiere XL, by chance, that comes from the factory with a 1TB drive?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-26-2013, 03:57 PM   #6
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
@unitron: The model number is TCD748000. Yes, you are correct that it is a Premier XL.

@jmbach: I have some info, but I think I am missing something in the mfslayout command.

To start with, when I try to do Expand, I get the following report (long numbers eliminated):
Size of Zones
Used 915.68G
Free 11.68G
Total 927.36G
Recordable Space 927.36G

I eventually figured out that to run the mfslayout I had to eXit from the JMFS program to get to the prompt and then type:
sh mfslayout.sh

The result that I get (ignoring the disclaimer at the top) is:
Java.lang.Exception: No root MFS found
at tivo.Mfs.addDisks (Mfs.java:309)
at tivo.Mfs. <init>(Mfs.java:74)
at tivo.Mfs. <init>(Mfs.java:68)
at jmfs.Mfslayout.main(MfsLayout.java:42)


Do I need to type the command differently? In particular, do I need to specify the drive to be looking at?
Oregonian is offline   Reply With Quote
Old 01-26-2013, 04:05 PM   #7
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Quote:
Originally Posted by Oregonian View Post
@unitron: The model number is TCD748000. Yes, you are correct that it is a Premier XL.

@jmbach: I have some info, but I think I am missing something in the mfslayout command.

To start with, when I try to do Expand, I get the following report (long numbers eliminated):
Size of Zones
Used 915.68G
Free 11.68G
Total 927.36G
Recordable Space 927.36G

I eventually figured out that to run the mfslayout I had to eXit from the JMFS program to get to the prompt and then type:
sh mfslayout.sh

The result that I get (ignoring the disclaimer at the top) is:
Java.lang.Exception: No root MFS found
at tivo.Mfs.addDisks (Mfs.java:309)
at tivo.Mfs. <init>(Mfs.java:74)
at tivo.Mfs. <init>(Mfs.java:68)
at jmfs.Mfslayout.main(MfsLayout.java:42)


Do I need to type the command differently? In particular, do I need to specify the drive to be looking at?

I think it's

/root/mfslayout.sh

even though the command prompt already says /root

Are you sure you're copying from the 1TB to the 2TB and then telling it to expand the 2TB and not the 1TB, 'cause it looks like it's not seeing that unused 1TB.

But if you can get mfslayout to work and post that partition map here, that'll give us some info that might help figure out what's going on.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-26-2013, 04:09 PM   #8
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
Progress!
I ran the following command:
sh mfslayout.sh /dev/sda

and I believe it outputted the information that you wanted.

It listed 18 physical zones, one of which is about 400G in size, the last one is over 500G in size. If I read it correctly, it is just telling me that the zones run out to the 1T point and no further.

If you can give me some clues, I can try to capture the output. I tried connecting a USB stick before booting and accessing it with: ls /dev/sdc, but that didn't work (no such file or directory). I was hoping to redirect output of the mfslayout command to a file so I could post it here. Is there an easy way to access either a USB stick or the floppy drive from the JMFS command line?
Oregonian is offline   Reply With Quote
Old 01-26-2013, 04:15 PM   #9
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Quote:
Originally Posted by Oregonian View Post
Progress!
I ran the following command:
sh mfslayout.sh /dev/sda

and I believe it outputted the information that you wanted.

It listed 18 physical zones, one of which is about 400G in size, the last one is over 500G in size. If I read it correctly, it is just telling me that the zones run out to the 1T point and no further.

If you can give me some clues, I can try to capture the output. I tried connecting a USB stick before booting and accessing it with: ls /dev/sdc, but that didn't work (no such file or directory). I was hoping to redirect output of the mfslayout command to a file so I could post it here. Is there an easy way to access either a USB stick or the floppy drive from the JMFS command line?

You probably have to mount them first.

do

ls -l

and see what you have for virtual directories to use as mount points, but first, what do you get for

sh mfslayout.sh /dev/sdb

?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-26-2013, 04:26 PM   #10
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
ls -l outputs a listing table with lots of information. I'm skipping most of it here (too much to type unless really necessary). All lines have "root root" in them. The ends of each lines are as follows: (I am retyping these, so there may be minor errors.)
.
..
.mc
.bashrc
.Profile
COPYING
README
USAGE
copyDisk.sh
guide.sh
jmfs-rev104.jar
jmfs.sh
log.log
mfsadd.sh
mfslayout.sh


sh mfslayout.sh /dev/sdb gives the "no root MFS found". My presumption from all of this is that /dev/sda is the 2T hard drive.
Oregonian is offline   Reply With Quote
Old 01-26-2013, 04:31 PM   #11
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Quote:
Originally Posted by Oregonian View Post
ls -l outputs a listing table with lots of information. I'm skipping most of it here (too much to type unless really necessary). All lines have "root root" in them. The ends of each lines are as follows: (I am retyping these, so there may be minor errors.)
.
..
.mc
.bashrc
.Profile
COPYING
README
USAGE
copyDisk.sh
guide.sh
jmfs-rev104.jar
jmfs.sh
log.log
mfsadd.sh
mfslayout.sh


sh mfslayout.sh /dev/sdb gives the "no root MFS found". My presumption from all of this is that /dev/sda is the 2T hard drive.

You might have to create a directory to have a mount point, but let's sort out which drive is which first.


hdparm -i /dev/sda


hdparm -i /dev/sdb


hdparm -i /dev/sdc


etc.

I assume you have both the 1TB and the 2TB drives connected to the PC?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-26-2013, 04:33 PM   #12
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
@unitron re: 1T vs. 2T
The 1T drive is removed from all systems at the moment. The PC I am using to do the JMFS stuff has all drives disconnected except for the 2T WD drive (WD20EURS), a floppy drive, a DVD/CD-RW drive, and a 4G USB stick.
Oregonian is offline   Reply With Quote
Old 01-26-2013, 04:38 PM   #13
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
hdparm -i /dev/sda gives a long listing of information
It starts with identifyin the disk as the WDC WD20EURS
If there is anything in particular you want from that, let me know and I'll type it.

hdparm -i /dev/sdb results in:
HDIO_GET_IDENTITY failed: invalid argument

hdparm -i /dev/sdc results in:
/dev/sdc No such file or directory
Oregonian is offline   Reply With Quote
Old 01-26-2013, 04:45 PM   #14
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
I was trying to pin down which drive was which 'cause I didn't know you didn't have the source drive connected.

I'm going to have to quit now and come back tomorrow, but do this

hdparm -N /dev/sda

and make sure you have the same number on both sides of the /

Then shut things down and go do something else.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-26-2013, 04:51 PM   #15
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
I think you are on to something here!
When I run hdparm -N /dev/sda, I get: (hand-typed may not be perfect)

Max sectors = 18446744073321613488/3907029168 (18446744073321613488?), HPA setting seems invalid
Oregonian is offline   Reply With Quote
Old 01-26-2013, 05:43 PM   #16
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
I looked further into the HPA issue and concluded that I need to remove it. To that end, I ran the following from the command prompt in JMFS:

hdparm -N p3907029168 --yes-i-know-what-i-am-doing /dev/sda

It comes back with:
Setting maximum sectors permanently
Max sectors = 18446744073321613488/3907029168 (18446744073321613488?), HPA setting seems invalid

So.... it didn't change anything. Same results after rebooting.

The good news is that I didn't trash the drive!

I looked further into the issue and found HDAT2. When I run it on the drive, it tells me that the Current Native and Current User areas are 2.0T each and the Hidden Area is 0 bytes.

So.... it appears that this is not a simple HDA issue. I am presuming that the real problem is that Max Sectors is set to 18..... which is way too large, although I don't understand why JMFS sees that value and HDAT2 does not appear to. The 3907029168 number seems correct because if I multiply it by 512 bytes/sector I am right at 2Tbytes.

My presumption here is that the Max Sectors value is wrong and needs to be corrected. Does this seem correct and, if so, how can it be done?

As always... many thanks for your input. It is greatly appreciated.

Last edited by Oregonian : 01-26-2013 at 07:23 PM.
Oregonian is offline   Reply With Quote
Old 01-26-2013, 09:52 PM   #17
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Quote:
Originally Posted by Oregonian View Post
I think you are on to something here!
When I run hdparm -N /dev/sda, I get: (hand-typed may not be perfect)

Max sectors = 18446744073321613488/3907029168 (18446744073321613488?), HPA setting seems invalid
Interesting. If I am seeing this straight the max sectors is greater than the native sectors of the drive. The first number should be less than or equal to the second. I guess the duplicator did something funky.

I wonder if copying block 0 of your good 1TB drive to block 0 of the 2TB drive would resolve the issue. Whatever the disk duplicator did is not permanent based on your experiment with the 1.5TB drive. Do you have any utilities that can read / write drive blocks. The only other block that may need to be copied is block 1. Could use your 1.5TB drive as the drive to experiment with. Would copy the first terabyte of your 2TB drive to the 1.5TB. Then try the copy.

Just a thought.

Sent from my SPH-L710 using Tapatalk 2
__________________
"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 01-26-2013, 11:07 PM   #18
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Another thought. You had hdat2. Have you tried the solution found in the FAQ question 1 on http://www.hdat2.com/ just for fun.....maybe
__________________
"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 01-27-2013, 07:38 AM   #19
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Quote:
Originally Posted by Oregonian View Post
I looked further into the HPA issue and concluded that I need to remove it. To that end, I ran the following from the command prompt in JMFS:

hdparm -N p3907029168 --yes-i-know-what-i-am-doing /dev/sda

It comes back with:
Setting maximum sectors permanently
Max sectors = 18446744073321613488/3907029168 (18446744073321613488?), HPA setting seems invalid

So.... it didn't change anything. Same results after rebooting.

The good news is that I didn't trash the drive!

I looked further into the issue and found HDAT2. When I run it on the drive, it tells me that the Current Native and Current User areas are 2.0T each and the Hidden Area is 0 bytes.

So.... it appears that this is not a simple HDA issue. I am presuming that the real problem is that Max Sectors is set to 18..... which is way too large, although I don't understand why JMFS sees that value and HDAT2 does not appear to. The 3907029168 number seems correct because if I multiply it by 512 bytes/sector I am right at 2Tbytes.

My presumption here is that the Max Sectors value is wrong and needs to be corrected. Does this seem correct and, if so, how can it be done?

As always... many thanks for your input. It is greatly appreciated.

Did we ever establish if you're using a GigaByte brand motherboard or not?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-27-2013, 01:13 PM   #20
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
One other thought. There are newer hdparm versions available. Wondering if you can get one of the latest linux distro on a USB key and run hdparm from there. Might be able to make the changes. I am guessing that JMFS is only seeing the first 10 numbers of the max sector number (1844674407) which is close to 1TB (1950866432) and therfore nothing to expand. So maybe using a newer hdparm version you could reset it or possibly using HDAT2 and going through the reset process eventhough it states everything is fine. My only other idea would be to copy block 0 and 1 of the good drive to the "bad" drive. When you copied the 2TB to the 1.5TB drive with JMFS you could not expand it. Presumably because the the same sector reporting issue. Would of been interesting to see hdparm information on the 1.5TB after you copied it to see if it actually was the case. When you copied the good 1TB to the 1.5TB you were able to expand it. So whatever happened is not permanent. Presumably if you copy the 1TB to 2TB with JMFS you could expand it. This is assuming what I have already said is correct. Experimenting is going to help. Wish there was some way to flash copy instead of taking hours.
__________________
"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 01-27-2013, 03:23 PM   #21
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
" If I am seeing this straight the max sectors is greater than the native sectors of the drive."
Yes... it is greater. More significantly though, is the fact that it is 20 digits long vs. 10 digits for the correct number of sectors.

"Did we ever establish if you're using a GigaByte brand motherboard or not?"
Never discussed that here, but it is a Biostar MCP6P M2+.
I have another test bench computer here with an ASUS board in it. I may try it for some of the next tests.

In order to be more cautious (and to not disrupt the working Tivo), I'm going to re-copy the 1T drive to the 1.5T drive using the duplicator. Before and after the copy I am going to see what hdparm -N tells me. I'm betting that the 1T (original Tivo drive) will have proper numbers. With this process I will have a 1.5T drive on which I don't have to worry about trashing data.

I like the idea of copying blocks 0 and 1 to the new drive, though I'm not sure how to accomplish that. I have Windows-based utilities that can do that, but I've seen many warnings about accessing a TiVo Premiere drive under Windows. In any case, if I use the 1.5T copy, I won't waste anything except time.

"When you copied the good 1TB to the 1.5TB you were able to expand it."
I may not have been clear on that one. I used JMFS to copy the 1T drive to the 1.5T drive and all went well.

"Presumably if you copy the 1TB to 2TB with JMFS you could expand it"
I expect that you are correct. This is what I should have done originally instead of using the disk duplicator. If it weren't for the fact that the 2T drive has been in service for over a month now (and has lots of new recordings), I would just erase it and recopy from the 1T using JMFS as I should have in the first place!

I'm going to recopy the 1T to the 1.5T with the disk duplicator, see if the problem is recreated, then try the suggestions above (different hdparm, HDAT2 FAQ, block copying) and see what I find.
Oregonian is offline   Reply With Quote
Old 01-27-2013, 03:45 PM   #22
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Quote:
Originally Posted by Oregonian View Post
" If I am seeing this straight the max sectors is greater than the native sectors of the drive."
Yes... it is greater. More significantly though, is the fact that it is 20 digits long vs. 10 digits for the correct number of sectors.

"Did we ever establish if you're using a GigaByte brand motherboard or not?"
Never discussed that here, but it is a Biostar MCP6P M2+.
I have another test bench computer here with an ASUS board in it. I may try it for some of the next tests.

In order to be more cautious (and to not disrupt the working Tivo), I'm going to re-copy the 1T drive to the 1.5T drive using the duplicator. Before and after the copy I am going to see what hdparm -N tells me. I'm betting that the 1T (original Tivo drive) will have proper numbers. With this process I will have a 1.5T drive on which I don't have to worry about trashing data.

I like the idea of copying blocks 0 and 1 to the new drive, though I'm not sure how to accomplish that. I have Windows-based utilities that can do that, but I've seen many warnings about accessing a TiVo Premiere drive under Windows. In any case, if I use the 1.5T copy, I won't waste anything except time.

"When you copied the good 1TB to the 1.5TB you were able to expand it."
I may not have been clear on that one. I used JMFS to copy the 1T drive to the 1.5T drive and all went well.

"Presumably if you copy the 1TB to 2TB with JMFS you could expand it"
I expect that you are correct. This is what I should have done originally instead of using the disk duplicator. If it weren't for the fact that the 2T drive has been in service for over a month now (and has lots of new recordings), I would just erase it and recopy from the 1T using JMFS as I should have in the first place!

I'm going to recopy the 1T to the 1.5T with the disk duplicator, see if the problem is recreated, then try the suggestions above (different hdparm, HDAT2 FAQ, block copying) and see what I find.

Before you do anything tell me about this disk duplicator so that I might google it and find out exactly how it does what it does, and whether that's preferable to running

dd

or one of its descendants.


The 1.5 is where you have all the old recordings and a month or so of newer ones as well, correct?
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-27-2013, 04:15 PM   #23
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,774
Apparently if a drive has an HPA (intentionally), then

hdparm -N

returns something like

max sectors = 586070255/586072368, HPA is enabled

so that the

xxx/yyy

part has the

xxx

as what the drive reports to OS'es and such, and the

yyy

part as what it really is.

So for some reason your 2TB is reporting what it really is correctly, but the "here's the lie we tell the OS" part is way screwy.

If I don't pass out I'll try to run

hdparm -N

on a 20EURS I haven't quite finished installing and see what I get.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Old 01-27-2013, 04:31 PM   #24
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Maybe we are over thinking this whole thing. Even though it is not a Gigabyte motherboard, some Googling indicates other motherboards may have problems as well. May be when you are doing this hook a "scrap" drive up to the first Sata port. If the HPA information looks similar with max sectors > native sectors we have our answer.

Sent from my SPH-L710 using Tapatalk 2
__________________
"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 01-27-2013, 07:32 PM   #25
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Also I would disable any RAID settings in the BIOS.

Sent from my SPH-L710 using Tapatalk 2
__________________
"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 01-27-2013, 09:55 PM   #26
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
No RAID settings in the BIOS.

I looked at my original 1T hard drive in the same system, same cable, same JMFS disk and it does not show the symptom. That is, hdparm -N shows the same number of sectors before and after the /.

I now have the 1.5T as a copy of the original 1T with the same symptom (huge number before the / in hdparm -N). I tried to Expand it with JMFS and it made it to 1.36T, but gave an error and won't use the whole drive. The good news is that this means that I have a drive I can mess with with no fear of losing data.

I tried the 'Restore' command in HDAT2 and got an error:
Aborted Command
Vendor Specific: 0002h Device is now in Security Locked Mode
Word Location: 00h Invalid Data Structure revision
Byte Location: 0000...00b

The 1T drive is my original TiVo drive that was removed from the system over a month ago.
The 1.5T drive is a copy of the 1T drive, so it doesn't have current data.
The 2T drive is in the TiVo and has current data.

I booted Knoppix 6.7.1 (I know, not the latest, but I had the CD already), ran the Terminal Emulator and ran:
sudo hdparm -N /dev/sdb
and got
Max Sectors = 2930277168/2930277168 HPA is disabled

This was with the 1.5T drive. It moved to /sdb because there is now another drive in the system.

I rebooted to the JMFS disk and ran:
hdparm -N /dev/sdb
and got
Max sectors = 18446744073321613488/2930277168 (18446744073321613488?), HPA setting seems invalid

So... it seems to be an issue with the HDPARM command on the JMFS disk.

Just to rule out hardware issues, I did the same test with JMFS and the 1.5T drive in a system with an Intel D945GCCR motherboard. HDPARM reports the same results on this board as on the Biostar motherboard. I didn't test with Knoppix on the Intel, but I am assuming that it will give the correct results.

The Biostar motherboard DOES support RAID, but I have that disabled.

So.... could I move the hdparm command from Knoppix to JMFS? Do you think that might do the trick? Is there some way I can run JMFS from within Knoppix?
Oregonian is offline   Reply With Quote
Old 01-27-2013, 10:36 PM   #27
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
Maybe compiling jmfs from source on newer Linux kernel. I guess the other thing would be to copy the 1TB to 1.5TB via jmfs and see if we still get the same HPA problem. If not then the duplicator I'd doing something. Might still be a block 0 issue. Here is a link that has some HPA information http://blog.atola.com/restoring-fact...rive-capacity/ which might be of some help.

Also it blows my idea that it was reading the first 10 digits for drive size. Because if it did then it would not have expanded at all.
Sent from my SPH-L710 using Tapatalk 2
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton

Last edited by jmbach : 01-28-2013 at 12:26 AM.
jmbach is offline   Reply With Quote
Old 01-28-2013, 12:27 AM   #28
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
More info.....

On the Biostar motherboard I ran JMFS hdparm -N on a 1.5T hard drive that has never known Linux or TiVo at all. I get similar bad results as with the other 1.5T drive.

I downloaded a new copy of JMFS 1.0.4 and burned it to a CD and got the same results.

(more to follow shortly)

Last edited by Oregonian : 01-28-2013 at 12:35 AM.
Oregonian is offline   Reply With Quote
Old 01-28-2013, 12:30 AM   #29
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 848
The other interesting thing is that the 20 digit number looks the same for both the 1.5TB and 2TB drive. Curious.

Sent from my SPH-L710 using Tapatalk 2
__________________
"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 01-28-2013, 12:41 AM   #30
Oregonian
Registered User
 
Join Date: May 2012
Posts: 49
I tried JMFS hdparm on a 120G drive on the Intel motherboard and got:
Max Sectors: 234441648/16337840(234441648?) HPA setting seems invalid (buggy kernel device driver?)

The 234441648 is likely correct for the 120G drive. It is not at all clear to me why it is reporting the second number (implying an 8G drive size).

I'm thinking that this has nothing to do with my disk duplicator as it was never used with the 120G drive or the second 1.5T drive. This looks more like an issue with JMFS hdparm not reading drives correctly in my two computers.

I must correct an earlier statement that I made. I said that I had successfully re-copied the 1T to the 1.5T using JMFS. To be honest, at this point I'm not sure it was successful. I'm going to start a copy tonight with JMFS to see what happens. Considering that it sees the size incorrectly right off the bat (even with the drive that has never seen Linux or TiVo), I'm not optimistic.
Oregonian 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 01:42 PM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |