Separate names with a comma.
Discussion in 'DIRECTV Tips and Resources' started by marty45714, Sep 25, 2007.
recheck what max version is WORKING for the method (search in the thread and forum)
Latest version no, earliest version yes
gparted 0461 works
I think you misunderstood my post. I do not have an issue with the xfs tools. It's that the large disk shows as unallocated when it certainly is. In any event, using the 3.3.7 version of gparted makes no difference here.
Are you saying you dont think your HR21 is properly formatting the new drive? It may not have anything to do with gparted at all. It HAS to be formatted by your HR21 b4 you try to do the xfs dump/restore. When you boot up your HR21 with the new 2TB drive attached, it has to come all the way up, including the format. If you dont see the message about formatting storage device, you cant go on to the next step.
No, not saying that. The HR21 formats the drive, boots it fine, runs with it fine. Even does a software update. But when I do the proper shutdown and try to view the disk under Linux, it shows as unallocated. I even tried ignoring the gparted indication of unallocated and doing the mount and xfs copy commands anyway - they didn't work. The old drive shows up with the partitions fine in gparted.
Use the version of gparted in the original post. That's the only thing I can suggest.
As I indicated earlier, I did try that exact version. I am 99.99% confident it is not a tool problem.
I have some other things I will try, but it will be a while before I can get to it.
was your new target drive clean ? perhaps without MBR you could see these old parts ...
@sbl The partitions are there on your new drive (assuming you had the receiver format it and it dismounted cleanly). Use the commands to mount the new drive (first post), then if you want to check run:
ls -alh /mnt/fap
You should see pretty much the same file structure as /mnt/hr20 (or whatever you mount these to).
I had the same issues you did with the latest version of the XFStools but 0.4.6-1 of gparted seems to be working much better so far. If you have a lot of stuff on your original drive it will take a while, so be patient.
I am trying to copy an external to an external. I have done this before several times with success. Using the same bootable devices for gparted as before.
I am getting an error from xfsrestore.
Says xfsrestore: attemp to write xxxxx bytes to viewer/segments/Rcrd-xxxxxxxxx(date timestuf.....mpg/xxxxxx at offset xxxxx failed: Invalid argument.
Anyone seen this before? The drive formatted in the dvr.
The errors appear to be data related as it will spit out errors on a recording and then continue a while w/o any errors. Later the errors resume on another file.
Is there anyway to redirect the output to a file instead of the screen so I could get a log of what recordings are bad? I can see channel, date and time which would be enough to id the recording.
I wrote down the date/time/channel information on some of the files that were getting a copy error. I then checked the old hard disk to see if these recordings existed. They did not. It appears that either they were deleted programs or programs where I had bad weather and the recording failed.
I also compared all the recordings on the new disk and the old and they were identical. So all the recordings were copied.
My conclusion is the errors I was receiving was due to some kind of disk corruption on the original disk.
As a test, today I am copying back from the new disk to the old. I am not getting any of the errors.
These errors appear to be that there are files on the hard drive which are not in the directory. In windows/dos they were called lost files and could be recovered with a dskchk.
I do wonder if these were taking up space that could not be used for recording, or if they are truly nothing to worry about.
You could use xfscheck program, if you want to dig into it.
xfscheck is a unix utility i presume?
Too late for this particular disk as I copied it to a new drive and then back just to see if the copy fixed it.
I wonder if anyone has tried xfscheck. These partitions appear to be non-standard.
My second copy has finished. All the recordings still there. Shows the same %free.
I did ... I recall the program/utility has been mentioned before here ... also it was outlined a process of recovery XFS with broken superblock and some other issues...
Non-standard to what OS and file system?
It's really just good ole xfs with some ext3 partitions or vice versa. I may have said that wrong but I'm not a big Linux guy either. To linux guys its pretty standard fare.
Non-standard in that GParted wont even show how much space is used in the largest partition. GParted wont copy the partitions (at least for me the copy option is not enabled).
You cant use gparted to do straight copies, your only option is really to do xfsdump and restores. I believe thats because the data is encrypted. I also believe that gparted doesnt show the statistics for the large partition because its a real-time subvolume and they arent like conventional partitions that us Windows guys are used to seeing.
When GPartEd will fully support XFS partitions with real-time extension, then the misrepresentation ("non-standard") of it will gone form posts ...
FYI: encrypted data and any other data (a content of files) is not an obstacle for XFS tools or other programs supporting the file system type.
I ran into something similar. I have a 750GB drive attached externally to a HR20-100. Contains maybe 30 recordings. The drive works fine installed internally or connected by eSATA. The other day I attempted to copy the drive to a new 1TB drive. Did the graceful shutdown with the 750GB drive, connected the 1TB drive by eSATA, let it format and then performed the graceful shutdown again. Moved both drives to a computer and booted up with GParted. The 1TB drive shows 3 partitions while the original 750GB drive show unallocated. I tried multiple versions of GParted that are listed in this thread as well as the latest version. Also tried these versions on different systems with the drive connected to the motherboards' native ports as well as eSATA and the 750GB drive always shows as unallocatted. Currently the 750GB drive is connected to the receiver and is still working fine.