Separate names with a comma.
Discussion in 'DIRECTV Tips and Resources' started by marty45714, Sep 25, 2007.
Try other version of Gparted...
I have tried 0.3.7-7, 0.4.4-1, 0.4.6-1 and 14.1-6. They all show the working drive as unallocated. I will mess with this more in the coming days. It is a strange situation though.
I would switch to Ubuntu CD, get some info by fdisk ...
I have tried the Ubuntu CD and fdisk, and various gparted versions as shown above. All fail for me as well.
I'm sorry, but the DVR's Linux cannot work without a partition. Try WinHex to investigate the phenomena.
My sincere thanks and appreciation to everyone who has contributed to this thread!!
Last Sunday, our external 1TB drive (WD DVR Expander) 'crashed'. Our primary HR21-100 would not start up and the receiver displayed a diagnostic code for a significant disk error. Running the receiver's internal HDD utilities showed failure in running LBA short and LBA long tests. But since the file system test was successful, I hoped to be able to salvage some of the recordings (the disk was about 83% full).
Thanks to the information in this thread, I was able to successfully recover all recordings (over 810GB). The copy process required over 19 hours(I copied using USB), but it was successful!
The new 2TB WD green HDD is only 60% full, so the extra space is a 'bonus'.
Thanks again to all of the posters for their technical insights & tips!
Old/Source drive: Seagate 750GB (full and getting flaky) in Antec MX-1
New/Destination drive: WD 2 TB EURS
Using Gparted 3.7-7 for procedure
Performed appropriate shutdown of old drive in DVR.
Installed new drive into Antec, powered up, powered up DVR and let formatting of drive conclude successfully
Performed appropriate shutdown.
Attached both drives via USB (1 in Antec, 1 via SATA->USB adapter cable) to laptop PC
Verified that both drives are visible in Gparted with appropriate sizes
Followed instructions from post #1 to create mount points and successfully mounted both drives
Executed xfsdump | restore commands
xfsrestore command was spitting out many "xfsrestore: attempt to write xxxxx bytes to viewer/segments/..... at offset yyyyyy failed: Invalid argument"
Quit dump/restore via ctrl-C
Unmounted old drive
Successfully Ran xfs_repair -L -r /dev/sdc3 /dev/sdc2
Remounted old drive
Again ran xfsdump | xfsrestore commands
xfsrestore failing with "ERROR: -R option required to resume or -Q option required to force completion of previously interrupted restore session"
I've read through the man pages for xfsrestore and hunted over the web and can't find a way to start from the beginning (i.e. ignore/overwrite the existing contents of the drive being restored to). I believe that this is what I want do given the errors I was previously encountering - versus resuming.
1. How do I indicate to treat the dest disk as empty?
2. What should I have used to interrupt the xfsdump | xfsrestore commands, if not ctrl-C?
1) Repeat your dump|restore command with -Q added to the restore part
2) Re-initialize your new/replacement drive in the HD-DVR ... to do so, you should first clear its MBR (sector #0). Do this at the command prompt under the GPartEd with the command:
dd if=/dev/zero of=/dev/sdX count=1 (make damn sure that X is correct!!)
Note that sdX will be the entire drive, and X is just a letter. None of the partitions/filesystems on sdX should be mounted. Once (re-)initialized, you can reissue the standard dump|restore command (without -Q)
Thanks - I will give this a go when I get home tonight. I had read the definition of the -Q option (as it was part of the error message) but didn't consider it as appropriate. I appreciate the help and will post results.
Success. After re-initializing/re-formatting (with the DVR) the new drive, I again ran xfsdump | xfsrestore. It completed far too quickly (a couple of hours at most) and while xfsrestore indicated success, xfsdump indicated failure. I gave it a try with the DVR anyway and it came up valid but empty. I did some more reading about xfs_check and xfs_repair. As a result I mounted the old drive (to replay the log), unmounted it and ran xfs_check to get a view of the disk state. I then ran xfs_repair -r /dev/sdc3 /dev/sdc2 to clean things up. I actually ran xfs_check/xfs_repair several times as I was getting some anomalous info from xfs_check. I then again ran xfsdump | xfsrestore. I continued to get the "xfsrestore: attempt to write xxxxx bytes to viewer/segments/..... at offset yyyyyy failed: Invalid argument" errors, but I let it run. After roughly 12 hours it completed with both xfsdump and xfsrestore reporting success. Powered down the drive, powered down the DVR, attached the drive, powered up the DVR and...success. Season passes intact, recordings intact, etc. 67% free. It was a good feeling both for it to be successful and to learn something (admittedly minimal) about Linux and the xfs file system (I read a bunch of man pages before and during this).
Thanks all for the help.
I followed the instructions. I did a reset - reboot and once the lights went off I unplugged the HR-20. Then I took out the original hard drive.
Then I inserted the new hard drive and hooked it up inside the HR-20 and started up the HR-20. Then after a system check it stated formatting hard drive. That went well too. Then when the TV picture came back up I went again to settings reset - reboot, and when the lights went out I unplugged the receiver.
Now when I plug in the old and the new driver and start with Gparted I can see all of the partitions on the old drive, however on the new drive I see just one large unalocated space. No partitions at all.
So I thought maybe I did a unclean shut down. I put it back in the DVR and started it up, but it started up without any issues. I even tried recording a show and it recorded fine. Again, when I do a receiver reset - reboot and unplug the unit once lights went off, and try to mount it in Gparted I get no partitions. Only a large unallocated block.
Am I doing something wrong? Do you have any advice? Please let me know.
That's second or third time ppl found the nuisanse ... if the DVR is accepting the drive, then there are some file system metadata ... I would try some forensic tool like WinHex.
I too just recently copied a 2TB EURS to a new 2TB EURS drive as I suspected the drive was beginning to have issues. Although the drive was not giving any errors during initial receiver self-check during reboot. xfsrestore command was spitting out many "xfsrestore: attempt to write xxxxx bytes to viewer/segments/..... at offset yyyyyy failed: Invalid argument" I could not get an xfs_check to run on a 2TB drive as it states out of memory due to the large disk size. I could not run an xfs_repair -n because it comes back and says it cant run on a device with realtime subvolumes. The dump restore routine completed successfully after about 10 hours or so. The new drive booted up in my HR fine, but there are little tiny dropouts or micro-stutters on most every recording, due to the failure of those little segments. So either the old drive was failing and its not allowing the reading of all the blocks/sectors on the old drive, or the indexing on the drive is messed up and the dump routine isnt looking in the right place for all the files pieces. I did use the xfs_repair -L -r /dev/sd?3 /dev/sd?2 command,and it completed without finding any issues at all, no missing file segments, etc.... I hooked the old drive back up and it is sluggish, but the little stutters go away in the same recordings, so it appears to be reading the segments that the the dump restore command cant copy over..... anyone have any ideas I might be able to try to do another copy and get all the missing file segments? This is the 1st drive copy I've really had any issues with, probably due to the source drive starting to fail.
yes, pretty old ... an idea ...I'm pushing it many times ... oh boy,am I a broken vinyl ?
Run MHDD from self-bootable CD, get SMART F8 first, save it; run Scan with Remap=on, see its log; run SMART again - compare results; perhaps run after that afew SMART tests to scrub out "UNC" and "Current pending sectors"
if you desperate using only Windows and cannot handle DOS, use Victoria for same actions [v4.46b is free]
So you think that SMART with remap will move some or all of the data from what you suspect are bad sectors? DOS is fine by me...I'll see if I can find MHDD when I get home
actually the MHDD will force HDD's FW to remap the sectors; any data what could retrieved will be copied to new good sectors
I realize this is an old post but I just tried this over the weekend. I have been waiting patiently for over 56 hours. It says 'restoring non-directory files' as the last line. The original drive was 300GB and was mostly full. I have a new 1TB 7200 rpm Seagate. I followed the instructions to the letter except that I had to type 'sudo' in front of each command to gain root priviliges. I received no errors when entering the commands. The drive was taken from my fully activated HR20 - 100s receiver. I don't have a SATA 0 but I have the new drive at Sata 1, old drive at Sata 2, and the bootable CD in Sata 3.
Using GParted 0.16.1
i5 Intel processor
Win XP Pro
It should not take this long. Any idea on what to try next?
it would be useful add timing parameter to watch activity:
if you didn't read last posts here, you missed very important moment: recover the drive by MHDD at physical level,
now you get to force read all bad sectors up to 20-100 times each ...
wait up to 48 hours I would say
I would go back and try to use a much older version of gparted....I am still using something like 0.3.9-1 or 0.4.6-1, or something close to that. On my i5 based desktop....works fine and doesnt need sudo for any commands. A 300GB drive should only take a couple of hours at most. I can copy a 2TB drive in 7-8 hours
the time above is estimated for good working drive, practically w/out bad sectors, ie sans mass retries