From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IuNpS-0006eT-Dk for garchives@archives.gentoo.org; Tue, 20 Nov 2007 07:47:30 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lAK7jfMS021703; Tue, 20 Nov 2007 07:45:41 GMT Received: from s200aog16.obsmtp.com (s200aog16.obsmtp.com [207.126.144.130]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lAK7jefQ021698 for ; Tue, 20 Nov 2007 07:45:40 GMT Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Tue, 20 Nov 2007 07:45:40 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E534BDA4B for ; Tue, 20 Nov 2007 07:45:39 +0000 (GMT) Received: from mail1.agr.st.com (mail1.agr.st.com [164.130.4.71]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8E8144BDE8 for ; Tue, 20 Nov 2007 07:45:39 +0000 (GMT) Received: from [164.130.17.81] (ws2912.agr.st.com [164.130.17.81]) by mail1.agr.st.com (MOS 3.7.5a-GA) with ESMTP id COG59091 (AUTH "raffaele belardi"); Tue, 20 Nov 2007 08:45:35 +0100 (CET) Message-ID: <47429114.5030102@st.com> Date: Tue, 20 Nov 2007 08:47:32 +0100 From: Raffaele BELARDI User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071113 SeaMonkey/1.1.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: not amd64 specific - disk failure References: <47415FCD.300@st.com> <47418F30.6050607@st.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 48bf5fda-a5b9-479f-bbdb-e4decafe8acf X-Archives-Hash: fe76d7d807ca6bf34e4b65eaa40a355b Duncan wrote: > If you have a spare drive of the same size or larger, you can try dd, or > probably better yet, merge dd-rescue and try it. They copy a file or > part of one, in this case an entire block device, from one location to > another, "raw". What you want to do is copy the entire bad device, /dev/ > sdc above, to the new device. Then you have a copy to play around with > without worrying about making the bad device worse before you get > whatever you were trying to get off of it, off. > Duncan, thanks for the ddrescue explanation, I will surely give it a try. Yesterday evening I got a new drive double the size of the damaged one, created a 250Gb partition on it and tried: # dd if=/dev/hdb of=/mnt/disk_500/sdb.img It stopped after few kb due to read errors. So I modified to dd conv=noerror if=/dev/hdb of=/mnt/disk_500/sdb.img and after some time I got a 250Gb sdb.img on the new drive. Then started the fun (it was already past midnight). When I created the new partition I noted down the superblock backup locations. Unfortunately, every: # e2fsck -b xxx -B 4096 /mnt/disk_500/sdb.img returned 'bad superblock'. After googling for some utility to scan disc for superblocks, I ended up with testdisk (it's ~amd64). To my understanding this works on real HW only, so I had to reconnect the damaged HD and let it do its job. testdisk found the superblocks, but according to it they were at the exact locations I had already noted, so no help. I also tried to let it search for partitions because I read it has an option to parse the directory. It worked, it let me see the list of lost files, but that's all, it has no option to recover. But at least it told me there is some good superblock somewhere. Finally I went back to the sdg.img and used "od | less" to look at what was present at the superblock location. What I saw was, I believe, a part of the superblock (an almost regular patter of numbers, increasing, which could be a list of blocks? I need to study ext2) but the point is that this pattern began well before the 'theoretical address' of the superblock. So my hypothesis is that the bad blocks or sectors at the beginning of the partition were not copied, or only partly copied, by dd, and due to this the superblocks are all shifted down. Although I don't like to access again the hw, maybe I should try: # dd conv=noerror,sync bs=4096 if=/dev/hdb of=/mnt/disk_500/sdb.img to get an aligned image. Problem is I don't know what bs= should be. Block size, so 4k? Any other option I might have? thanks, raffaele -- gentoo-amd64@gentoo.org mailing list