Jump to content


Welcome to DBSTalk


Sign In 

Create Account
Welcome to DBSTalk. Our community covers all aspects of video delivery solutions including: Direct Broadcast Satellite (DBS), Cable Television, and Internet Protocol Television (IPTV). We also have forums to discuss popular television programs, home theater equipment, and internet streaming service providers. Members of our community include experts who can help you solve technical problems, industry professionals, company representatives, and novices who are here to learn.

Like most online communities you must register to view or post in our community. Sign-up is a free and simple process that requires minimal information. Be a part of our community by signing in or creating an account. The Digital Bit Stream starts here!
  • Reply to existing topics or start a discussion of your own
  • Subscribe to topics and forums and get email updates
  • Send private personal messages (PM) to other forum members
  • Customize your profile page and make new friends
 
Guest Message by DevFuse

Photo
- - - - -

How to: Copy and Replace Internal Hard Drive


  • Please log in to reply
654 replies to this topic

Poll: I have read the disclaimer and I understand that this process in NOT recommended (606 member(s) have cast votes)

I have read the disclaimer and I understand that this process in NOT recommended

  1. YES - I agree I will not tamper with my leased equipment (420 votes [69.31%] - View)

    Percentage of vote: 69.31%

  2. NO - I agree to accept full financial responsibility for breaking my Customer Agreement (186 votes [30.69%] - View)

    Percentage of vote: 30.69%

Vote Guests cannot vote

#601 OFFLINE   CCarncross

CCarncross

    Hall Of Fame

  • Registered
  • 7,058 posts
  • LocationJackson
Joined: Jul 19, 2005

Posted 10 February 2014 - 11:30 AM

If the dump/restore completed...and the new drive boots up etc...the recordings will all play but many if not most of them will have little stutters in them that are the damaged/missing segments. 



...Ads Help To Support This Site...

#602 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 26 April 2014 - 03:58 PM

I'm experiencing the same problem as others here. I'm getting thousands of these errors during the xfsrestore:

xfsrestore: attempt to write XXXX bytes to v ewer/segments/XXXXX at offset XXXXXXX failed: Invalid argument

The result is that the new drive does work fine in the DVR, but I'm experiencing micro stutters (like others here) to video and sound. It's very annoying, to I tried a bunch of stuff to fix it.

The source drive IS NOT bad, read below on how I have verified this. I strongly believe that there is some other issue at work here, either with the XFS tools or something to do with XFS real time sparse files.

I tried xfsdump/xfsrestore using the following, all of them failed:

ubuntu 12.04 - apt-get install xfsdump
ubuntu 14.04 - apt-get install xfsdump
Gparted 0.18.0-2
Gpared 0.3.7-7
Gparted 0.4.6-1
Gparted 0.3.9-13

I also tried doing a xfsdump to a file on a temporary drive formated at ext4, and restoring from the file (i.e. no pipe), this also failed (tried it on Ubuntu and Gparted 3.7.7):

xfsdump -p 60 -f mydump /mnt/DVR
xfsrestore -p 60 -f mydump /mnt/NEW

I also tried an xfs_repair on my source drive and then repeated with Gparted 3.7.7 and Ubuntu and I'm getting the same result.

I took a sample of three different "Rcrd-xxxxxxxxx-.mpg" and all their segments that are failing. I did a straight Linux copy using "cp -a --sparse=never <source> <dest>" and then compared the binary result with "cmp" and the files were identical.

I also verified the content using "hexdump" at the address reported in the error, and when comparing the files produced by xfsrestore, they are different at the exact address reported in the error, but when comparing to the file produced by "cp -a --sparse=never", they are all identical.

Conclusion: I'm not having any issue reading from the source disk, I can reproduce the exact binary file over and over with "cp -a" but not with "xfsrestore". But here's what's interesting, when looking at the "hexdump" of the bad file, the error location is ALWAYS where a bunch of zeros begin. So I'm wondering if there is a bug somewhere on how the tools or filesystem are handling sparse files.

Other things to try:

So unfortunately, you cannot just use "cp -a" to copy over to the new XFS filesystem, this will work, but it won't use the real-time section (e.g. /dev/sda3) and will simply fill up your metadata section (/dev/sda2) with real files, using real space, so it will run out quickly (only 16GB).

I'm wondering if it's possible to copy just the XFS metadata using xfs_metadump to the new /dev/sda2 and then do a "dd if=/dev/sdb3 of=/dev/sda3" for the XFS real-time section. Question is whether this will work as the inod blocks will not necessarily be in the same place.

Anyone have any other ideas?


Edited by ixion, 26 April 2014 - 05:50 PM.


#603 OFFLINE   P Smith

P Smith

    Mr. FixAnything

  • Registered
  • 20,058 posts
  • LocationMediterranean Sea
Joined: Jul 25, 2002

Posted 26 April 2014 - 04:49 PM

"used 0.4.6-1 and all worked perfectly fine."

 

seems your versions is different ... did you omit "0," ?



#604 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 26 April 2014 - 05:51 PM

"used 0.4.6-1 and all worked perfectly fine."

 

seems your versions is different ... did you omit "0

 

"used 0.4.6-1 and all worked perfectly fine."

 

seems your versions is different ... did you omit "0," ?

Yes, forgot the leading 0. Fixed it.



#605 OFFLINE   P Smith

P Smith

    Mr. FixAnything

  • Registered
  • 20,058 posts
  • LocationMediterranean Sea
Joined: Jul 25, 2002

Posted 26 April 2014 - 06:24 PM

I would try to make another graceful shutdown of the DVR



#606 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 27 April 2014 - 02:37 PM

I did some more tests. I have confirmed that extracting a file from my XFS dump to an EXT4 filesystem directory results in a bit-perfect file with the original. I used xfsrestore in interactive mode and extracted a couple of viewer/segments/Rcvr-xxxx.mpg files. Then used "cmp" and "hexdump" to compare them and they are identical. 

 

So clearly, there is nothing wrong with the source or xfsdump, and the issue is ONLY when extracting and writing to the new XFS filesystem's real-time section on the new disk. The "micro failures" all occur at the end of the files (always within ~100 bytes of the end of the file) which in itself is very suspicious.

 

So I'm now wondering if this has something to do with the fact that the old disk is a 512 sector disk and the new one is an advanced format 4k sector disk. The xfs_info clearly shows this difference, but you would think that xfsrestore handles this fine.

root@ubuntu:/mnt# xfs_info /mnt/DVR
meta-data=/dev/sdd2              isize=256    agcount=16, agsize=245869 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=3933904, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =external               extsz=1048576 blocks=240123555, rtextents=937982
root@ubuntu:/mnt# xfs_info /mnt/NEW
meta-data=/dev/sdb2              isize=256    agcount=16, agsize=245869 blks
         =                       sectsz=4096  attr=0
data     =                       bsize=4096   blocks=3933904, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=0
realtime =external               extsz=1048576 blocks=484311554, rtextents=1891842



#607 OFFLINE   P Smith

P Smith

    Mr. FixAnything

  • Registered
  • 20,058 posts
  • LocationMediterranean Sea
Joined: Jul 25, 2002

Posted 27 April 2014 - 03:38 PM

umm, did you init the target drive in your DVR before copy to it ? is the drive taken out of DVR with graceful shutdown ?



#608 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 27 April 2014 - 09:20 PM

umm, did you init the target drive in your DVR before copy to it ? is the drive taken out of DVR with graceful shutdown ?

 

Yes, I did that. But you do have me wondering if this has something to do with it. Maybe I'll try erasing the partition table and trying again from scratch, making sure there is a graceful shutdown. I'll report back.



#609 OFFLINE   inkahauts

inkahauts

    Hall Of Fame

  • DBSTalk Club
  • 16,251 posts
Joined: Nov 13, 2006

Posted 27 April 2014 - 09:40 PM

I'm experiencing the same problem as others here. I'm getting thousands of these errors during the xfsrestore:

xfsrestore: attempt to write XXXX bytes to v ewer/segments/XXXXX at offset XXXXXXX failed: Invalid argument

The result is that the new drive does work fine in the DVR, but I'm experiencing micro stutters (like others here) to video and sound. It's very annoying, to I tried a bunch of stuff to fix it.

The source drive IS NOT bad, read below on how I have verified this. I strongly believe that there is some other issue at work here, either with the XFS tools or something to do with XFS real time sparse files.

I tried xfsdump/xfsrestore using the following, all of them failed:

ubuntu 12.04 - apt-get install xfsdump
ubuntu 14.04 - apt-get install xfsdump
Gparted 0.18.0-2
Gpared 0.3.7-7
Gparted 0.4.6-1
Gparted 0.3.9-13

I also tried doing a xfsdump to a file on a temporary drive formated at ext4, and restoring from the file (i.e. no pipe), this also failed (tried it on Ubuntu and Gparted 3.7.7):

xfsdump -p 60 -f mydump /mnt/DVR
xfsrestore -p 60 -f mydump /mnt/NEW

I also tried an xfs_repair on my source drive and then repeated with Gparted 3.7.7 and Ubuntu and I'm getting the same result.

I took a sample of three different "Rcrd-xxxxxxxxx-.mpg" and all their segments that are failing. I did a straight Linux copy using "cp -a --sparse=never " and then compared the binary result with "cmp" and the files were identical.

I also verified the content using "hexdump" at the address reported in the error, and when comparing the files produced by xfsrestore, they are different at the exact address reported in the error, but when comparing to the file produced by "cp -a --sparse=never", they are all identical.

Conclusion: I'm not having any issue reading from the source disk, I can reproduce the exact binary file over and over with "cp -a" but not with "xfsrestore". But here's what's interesting, when looking at the "hexdump" of the bad file, the error location is ALWAYS where a bunch of zeros begin. So I'm wondering if there is a bug somewhere on how the tools or filesystem are handling sparse files.

Other things to try:

So unfortunately, you cannot just use "cp -a" to copy over to the new XFS filesystem, this will work, but it won't use the real-time section (e.g. /dev/sda3) and will simply fill up your metadata section (/dev/sda2) with real files, using real space, so it will run out quickly (only 16GB).

I'm wondering if it's possible to copy just the XFS metadata using xfs_metadump to the new /dev/sda2 and then do a "dd if=/dev/sdb3 of=/dev/sda3" for the XFS real-time section. Question is whether this will work as the inod blocks will not necessarily be in the same place.

Anyone have any other ideas?


Without reading everything I can only suggest you do it exactly as is stated in this thread at the very beginning using the really really old version Of gparted. It's the only one I can get to work smoothly.

#610 OFFLINE   inkahauts

inkahauts

    Hall Of Fame

  • DBSTalk Club
  • 16,251 posts
Joined: Nov 13, 2006

Posted 27 April 2014 - 09:41 PM

Yes, I did that. But you do have me wondering if this has something to do with it. Maybe I'll try erasing the partition table and trying again from scratch, making sure there is a graceful shutdown. I'll report back.


It is extremely important that you do a menu restart only and unplug it as soon as it's done powering down but before it begins powering back up. That also causes weird issues if you don't do that.

#611 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 27 April 2014 - 09:58 PM

Ok, I zeroed out the partition table and reinitialized the new disk in the DVR (I saw the "formating storage" message on the DVR). I did a menu restart and unplugged after the light went out (I could hear the drive spining down), and before the unit booted up again. I put my drive back into my system and started the xfsrestore, same exact problem. I'm running out of options. 



#612 OFFLINE   P Smith

P Smith

    Mr. FixAnything

  • Registered
  • 20,058 posts
  • LocationMediterranean Sea
Joined: Jul 25, 2002

Posted 27 April 2014 - 10:34 PM

I would try old version of Ubuntu ...



#613 OFFLINE   ixion

ixion

    New Member

  • Registered
  • 6 posts
Joined: Apr 04, 2008

Posted 28 April 2014 - 04:27 PM

After all of this, I decided to re-install the old drive into the DVR. And upon further investigation, I noticed that the micro stutters are present in the source material at exactly the same spot in the video!

 

So I'm starting to think that the errors in xfsrestore are not the cause of the micro stutters at all. So after all this, I decided to install the new drive into the DVR and live with it. I now suspect that the old drive was intermittently having some errors and this is what caused the micro stutters, and since they are "recorded" in the source video, there's nothing I can do about it.  

 

Still though, it would be nice to know why xfsrestore is reporting all those errors. I still haven't gotten to the bottom of it after exhaustive hours of research and web searching. If anyone ever figures it out, please post a solution here!

 

Thanks all.   



#614 OFFLINE   Bigbwb

Bigbwb

    New Member

  • Registered
  • 4 posts
Joined: Jun 18, 2014

Posted 18 June 2014 - 04:58 PM

Quick question....
One of my HD dvr hr23-700 died last night due to a lightning storm. Tech support cannot get it to work. Anyway, I have an extra receiver (same model), is it possible to swap the hard drive of the damaged unit into the other box in order to keep my recordings if they survived?

Thanks,
Brandon

#615 OFFLINE   P Smith

P Smith

    Mr. FixAnything

  • Registered
  • 20,058 posts
  • LocationMediterranean Sea
Joined: Jul 25, 2002

Posted 18 June 2014 - 05:16 PM

Brandon, sorry to tell you truth, but you violated two basic rules of Internet from your first post: search&read and do not post off topic

you come to the specialized "Copy ..." thread to ask a question what was asked so many times - why ?

 

NO



#616 OFFLINE   Bigbwb

Bigbwb

    New Member

  • Registered
  • 4 posts
Joined: Jun 18, 2014

Posted 18 June 2014 - 05:36 PM

Sorry I asked. A simple response without the sarcasm would have sufficed. I lost quite a bit of gear last night in the storm so pardon my hurry to find an answer.

#617 OFFLINE   litzdog911

litzdog911

    Hall Of Fame

  • Registered
  • 11,712 posts
  • LocationMill Creek, WA
Joined: Jun 23, 2004

Posted 18 June 2014 - 05:40 PM

Quick question....
One of my HD dvr hr23-700 died last night due to a lightning storm. Tech support cannot get it to work. Anyway, I have an extra receiver (same model), is it possible to swap the hard drive of the damaged unit into the other box in order to keep my recordings if they survived?

Thanks,
Brandon

No, your recordings are encrypted to the DVR that made them.  You won't be able to access them in a different DVR, even if it's the same model.  


HD DVRs: HR34-700; HR24-500; (2) HR20-700 + WD eSATA 1TB drive/Antec MX1 case; HR21-700; HR21-200 w/AM21
Receivers: H25-500 HD Receiver; H21-100 HD Receiver
Mobile Devices: Nomad

Additional equipment configuration details

Sun & moon help site your satellite dish


#618 OFFLINE   Bigbwb

Bigbwb

    New Member

  • Registered
  • 4 posts
Joined: Jun 18, 2014

Posted 18 June 2014 - 06:01 PM

No, your recordings are encrypted to the DVR that made them.  You won't be able to access them in a different DVR, even if it's the same model.


Thank you for the response. Bummer. Well, I guess I'm SOL.

I suppose that was my only option to retrieve the recordings?

#619 OFFLINE   dpeters11

dpeters11

    Hall Of Fame

  • DBSTalk Club
  • 13,519 posts
  • LocationCincinnati
Joined: May 30, 2007

Posted 18 June 2014 - 06:21 PM

Thank you for the response. Bummer. Well, I guess I'm SOL.

I suppose that was my only option to retrieve the recordings?

 

Yeah, unfortunately not much can be done. There is this, but it seems to be a limited service right now and requires Protection Plan Plus.

http://www.dbstalk.c...ng-of-the-past/



#620 OFFLINE   Bigbwb

Bigbwb

    New Member

  • Registered
  • 4 posts
Joined: Jun 18, 2014

Posted 18 June 2014 - 06:45 PM

Yeah, unfortunately not much can be done. There is this, but it seems to be a limited service right now and requires Protection Plan Plus.

http://www.dbstalk.c...ng-of-the-past/

 

That's what I thought.  Well, at least lately many of the network shows I watch/record are available to view online.

 

Darn weather here in WI!

 

Have a great night folks!






Protected By... spam firewall...And...