Separate names with a comma.
Discussion in 'TiVo Underground' started by PortlandPaw, Aug 16, 2004.
Your best bet is to use the same brand as the current drives.
Thanks, I think that would probably be best too, but I don't have that option. At least I can't easily find my 2 original drives. I'm trying to get at solutions for my current problem. 2 120GB drives -> 2 120GB drives...
I am trying to dd_rescue a 160GB drive with a 200GB drive (I know I'm only getting 137GB of usable space). dd_rescue seems to be not responding, it copied about 80GB and now its just stuck there and hasnt changed the screen for hours. The HD light is on but if I press enter it forwards to the next line but no command promt. There are no errors while copying, so I dont know why its seems like its hanging.
should I kill it and try to start it again? or is there some other solution?
...I'm using the RIP CD and my dd_rescue command looks like this:
dd_rescue -B 1b -b 2M -A -v -l /var/dd_rescue.log /dev/sda /dev/sdb
I have the drives pluged in to the SATA ports and am using a SATA to PATA adapter, is that causing a problem, should I try to boot the CD from the SATA adapter and have the HDs on the IDE channel?
one more thing is it says: "dd_rescue: (info): about to transfer 0.0 kBytes from /dev/sda to /dev/sdb"
is that normal for it to say 0.0k?
These tips came from SR712 and were shamelessly copied from the forum which cannot be named. It explains how to set DMA on the source and target drives and set 2M block size to optimize the speed of copy.
After you boot into Linux, before you run the dd command:
hdparm -d1 /dev/hda /dev/hdc
[If you have the drives as hda and hdc.]
Then, use dd command like this to enable 2M block sizes:
dd if=/dev/hda of=/dev/hdc bs=2M
...if your source drive is hda and your destination drive is hdc.
hdparm -d1 /dev/hda /dev/hdc
dd if=/dev/hda of=/dev/hdc bs=2M
Why use dd?? In a dd_rescue thread? I'm appalled!
His dd_rescue command line clearly shows he's using a 2M buffer so I see no advantage reverting back to dd. Well, I can't see any reason do ever revert back to dd...
Oh and just so everyone is aware that hdparm command will only work if DMA support is gen'd into the kernel.
If you find this information isn't helpful, by all means, don't use it.
Well my only concern is that you're cutting and pasting this stuff without any explanation or background on the commands and people that are not UNIX/Linux savoy are going to use them and they may not work. That is not helpful to people to who UNIX/Linux is completely unfamiliar. Some expect to use these commands verbatim and expect them to work as described, that is not always the case.
Case in point, the hdparm command you posted may not work for reasons I already stated which are not fully inclusive.
Second, the dd command you posted has pitfalls, one of which is no status reporting of progress which was one of the key factors that dd_rescue has over dd because people couldn't tell if dd was really doing anything. And second, a much BIGGER pitfall is with the 2M blocking size in your posted dd command every time dd encounters a bad spot you could lose in the transfer up to that 2M instead of what dd_rescue does i.e. fall back to the 512 byte blocking factor so you only lose 512 bytes (one sector) verses 2M. This could be critical and render the target disk unbootable depending where this occurs. Of course a 512 byte loss could do that also but with the blocking factor being 2M in the dd command verses 512 bytes for dd_rescue's -B option you're increasing the chance of that happening 4000 to 1. Not good odds in my book, I'd never take those odds.
This blocking factor fall back along with the status reporting that dd_rescue does were two of the reasons I started using dd_rescue instead of dd and did all the testing and bought it and my results to this forum. Going back and suggesting dd be used again is a step backwards IMO, there's nothing that indicates dd will work where dd_rescue won't or vise versa. If dd_rescue hangs dd will most likely hang too and the hang is more then likely due to a hard disk that is having a major problem.
Pretty arrogant comment to make, then don't use them, when we're trying to help others especially for people that may not be technical and understand the difference between dd and dd_rescue.
I post only that which I believe to be helpful to people. If everybody here were to limit their posts to only that which they know to be 100% accurate and in language that 100% of the people could understand 100% of the time, it would be a very barren board, indeed.
I'm sorry if I've somehow offended your sensitivities or haven't risen to your level of quality. Makes me sorry I started this thread.
Now that I think more about it, that dd command may not work at all on a source disk that has sectors that cannot be read. Without conv=noerror dd will stop at the point it encounters the first read error, and without conv=sync dd won't pad the 2M block so it is a 2M block when it writes it. If it were to read 10K into the 2M block and have a problem it would write 10k, then when it read the next 2M it would put it on the target disk right after that last 10K and now you're skewing the data on the target disk by that loss of 1.99M and that could be across partitions because dd is a physical sector copy. I'm not 100% sure of this not ever having a chance to test it but that's the way the man pages read. The only thing I'm not sure of is where dd picks up the start for read of the next 2M block from the source disk, right after the sector it couldn't read or at what would have been the end of that last 2M read block. If it's the end of the 2M read block, that's when things would get screwed up. Next time I have a failed disk I'm going to explore this so I know once and for all. Course that wouldn't really happen anyway because you don't have the conv=noerror so it would stop.
That dd command will only work on a source disk that does not have any read problems, which is an oxy moron because in most cases there would be no need to dd it in the first place. So, without conv=noerror,sync that dd command is useless in attempting to copy a source disk that has read problems.
So, how is a command that will not work on a failing disk helpful? But I should just shutup and not use it....
Of that you shouldn't be. It's nice to have this info in a place where people can find it and of that you have done a good job. I was just concerned that someone would jump to the end of the thread and think that that dd command was now the command in fashion. Nothing personal. You did what I didn't have the time to do and that was to do this thread as a HowTo and IMO that was GREAT!
I'm having the same issue with dd_rescue on the PTV CD. The switches listed in the help file are different from the version I was using with Knoppix. There's no -B, -A, or -l, for instance, and -r has a different function (not reverse). I wonder if this is a different flavor of dd_rescue? (Google turns up a Diaz version vs. the Garloff version, which I assume is what I was using before and what the posts here refer to?)
When it finishes running on my machine I will get the available parameters so folks can compare the two versions and perhaps make recommendations about which ones the folks using the PTV CD should choose.
Here are the parameters for the version of dd_rescue on the PTV Upgrade CD:
Perhaps the dd_rescue experts can suggest the best configuration for this version. Obviously you want -v and the badblocks_file. If I'm understanding it correctly, -b correlates to -B and -c to -b, so I think you'd want -b 1b -c 2M. There doesn't seem to be a corollary for -A.
Did you ever sucessfully copy over your drive using dd_rescue from the PTVupgrade disk, and if so what string of paramaters did you use?
Another Maxtor 120 has failed on me, at 13 months of course. Turned on the TV to find it in a "Welcome! Powering up" loop.
After much crying (it *is* premiere week! ), decided to run out and get a drive and investigate my options. I had about 60 shows on there that were either about to be archived, or not yet watched.
Ended up getting a 200 GB WD (3-year warranty) to keep my options open. Decided to try dd_rescue and downloaded a Knoppix 3.9 Live CD. First I made a standard MFS_Tools 2.0 backup just to be safe.
I used the command as indicated in PP's updated post above, and it cruised along until hitting its first bad blocks at about 33 G. I let it go for a bit, then rebooted and invoked it again, this time to go in reverse. It flew along, transferring 45 G before the first errors. I went away for an hour and came back to find it was in good sectors again, so I rebooted and used the -s xxxxxxxxk flag to get it to start where it left off. I had to do this twice in all. I woke up this morning and the copy was complete, with a total of 1200K of errors. I figure my chances are good.
I popped the new 200 GB drive in the DSR6000 and booted up fine. I watched a bit of live TV and checked Now Playing to see that all my shows are there. I left for an appointment.
When I came home after a couple of hours, I was on a GSOD. I plugged in the Ethernet cable. After about 10 minutes, it tried to boot up. It gets through the CacheCard boot, to "Almost there..." then back to GSOD. This has repeated several times now in the hour I've been here.
Is TiVo trying to repair the null blocks, or is something else wrong? Should I let it keep cycling like this, or just give up on my recordings and SPs and just restore the MFS Tools image?
Update: Came home from work, and it was still rebooting into a GSOD loop.
Someone in HH suggested I Kickstart, so I went to alt.org and looked at the codes. Tried a 58, it rebooted then went into GSOD for over an hour. Then BAM, TV! At first, I was getting errors in TiVoweb, and the UI was as slow as without CacheCard. I could not search or check the To Do list and so forth. Did a reboot and it all cleared up. Fast and full-featured!
PortlandPaw, don't be sorry you started this thread! This thread just saved about 100 hours of programs for me! My 120GB Maxtor drive started to cause my HDVR2 to freeze so I knew that the drive was dying. I came to TCF and stumbled upon this thread. Thanks to you, PortlandPaw, I have my 100 hours back on a new Seagate drive.
Thank you very much!!!
The drive was badly injured, it took a long time for dd_rescue to perform its magic: more than 30 hours. But hey, having my programs back: priceless.
For the record, this is the second 120GB Maxtor drive that failed on me. This drive was a refurbished one I got as part of the warranty for the first one. It seems that Maxtor drives are causing a lot of problems for a lot of people, from the information I can gather here and there on TCF. Needless to say that I will never buy any Maxtor drives ever again!
BlankMan, I wish I had seen you thread about dd_rescue before I started restoring my failing drive with dd_recue because maybe it would have saved me a lot of time.
That said, whoever created dd_rescue is a genius!
I just had an 80 gig drive fail and replacing it with a 200 gig drive. If I want to try to rescue the data on my old drive, and copy it over, do I need to update the new drive with the new kernel for large drive support over 137 gigs, before I do the copying from the old drive?
After... and note that it won't make a difference if you don't do an mfsadd after you've done your rescue...
I am confused now. Do I just need to run CopyKern? Is mfsadd only for adding two drives in a Tivo machine? I see some posts referencing to use that for expanding the drive as well bigger than 137 gigs. Also, on the sticky, I see you mentioning the term "Bless". What does that mean?
FYI, I have a series 2 Toshiba SD-H400 Tivo machine.
I just downloaded the Universal Boot CD v.11 (I have a few ongoing projects). Does this version carry the dd_rescue tool? And is it the version of dd_rescue with the same switches as on the Live Linux distributions?
Crap. No errors on the drive. And a kickstart isn't working either - tried 58 and now 57.