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 1IuAHw-0006su-R0 for garchives@archives.gentoo.org; Mon, 19 Nov 2007 17:20:01 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lAJHHisT017511; Mon, 19 Nov 2007 17:17:44 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lAJHHibK017496 for ; Mon, 19 Nov 2007 17:17:44 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IuAEk-0001vq-Qb for gentoo-amd64@lists.gentoo.org; Mon, 19 Nov 2007 17:16:43 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 17:16:42 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Nov 2007 17:16:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: not amd64 specific - disk failure Date: Mon, 19 Nov 2007 17:14:59 +0000 (UTC) Message-ID: References: <47415FCD.300@st.com> <47418F30.6050607@st.com> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news X-Archives-Salt: bc190cb0-9bf0-4691-ae81-ff1a6ad88966 X-Archives-Hash: 995845a896faefae3715e7bf09deea0b Raffaele BELARDI posted 47418F30.6050607@st.com, excerpted below, on Mon, 19 Nov 2007 14:27:12 +0100: > Most of the resources I've read up to now imply that e.g. /dev/sdc1 is > detected and a 'bad superblock' message displayed when attempting to > mount. > > In my case the kernel is unable to detect /dev/sdc1, after the long list > of read errors below it ends up with only /dev/sdc. > > Does this look like superblock issue, or something worse? 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. dd-rescue is different than dd in that if there are bad blocks, it will run until it starts hitting them, then it will work backwards from the other end until it hits them there, then it'll try blocks in the middle. Thus, if you have good blocks, bad blocks, good blocks, bad blocks, good blocks, dd-rescue recovers more of the disk in a reasonable amount of time, as compared to straight dd, which will try straight thru only. (The problem is that once you start hitting bad blocks, everything slows down, because the system tries and retries the bad block multiple times before giving up, taking minutes to read a block or finally decide it can't, before moving on, where it'd read a good block in seconds. Thus, to work thru even a few hundred bad blocks can take DAYS. Giving up after a few and starting from the other end, then trying in the middle, increases the number of blocks recovered, without sitting there waiting for days for it to work thru all the bad ones and get to the rest of the good ones again, and that's what dd-rescue does for you, automates the give up and try from the other end and then in the middle stuff.) The thing to remember when working with either program is that you want to be **VERY** **SURE** you get the right devices specified, particularly for the output device. If you tell it to write to the device that your main system is on instead of the new empty device, it WILL overwrite your main system device, boot record, partition table, and all. Thus, make TRIPLE SURE you have the right output device specified before you hit that enter key. The reason I'm suggesting dd/dd-rescue is because they'll grab the raw data (what they can of it) directly off of the device you point them at (/ dev/sdc above, but as I said, be absolutely sure the devices aren't reordered after you attach the new one). Since you can't mount the partition, you need something that can grab the info off of the unpartitioned drive itself. Then, once you get a copy to work with, you can check what fdisk says about it and go from there. In fact, if the data is worth it and you have the money, you may want to get TWO replacement drives, one to make a "safe" copy to, and a second to make a working copy (from the safe copy) to. Then you play with the working copy, and if you screw up, you can simply recopy from the safe copy, without having to go back to the damaged drive -- because it's possible you'll only get the one chance to get stuff off of the damaged one. If the damage is severe enough dd-rescue can't pull anything off, consider wrapping the drive in paper for padding and moisture absorption) then plastic (preferably double- or triple-wrapped), then put it in your freezer overnight. There are quite a number of tales of folks that had dead drives that they were able to revive long enough by freezing them, to get the stuff or at least part of the stuff off that they needed to. Keep in mind that as soon as you take it out and plug it in, it'll start warming up, and you may only have a few minutes, if it's bad enough. In that case, if you have just a few smaller files you really want, you can hope the filesystem is usable again, and you may have time enough to retrieve them. If that's not the case, and you need to go for the bulk, then you can write down how far you get, then try freezing it again, and tell dd-rescue to start where it stopped the second time. Of course, you may have a limited number of times even freezing the drive will work, and you likely won't recover the entire thing this way, but if some is better than none... There are special forensics LiveCD distributions out there. Try STD and INSERT (google them, that's how I found them), both based off KNOPPIX, I believe. INSERT is small enough to fit on the small credit/business-card sized CD, 180 MB or some such. STD is a full-sized CD-image, basically a normal KNOPPIX only with enough stuff removed to load the extra forensics/ recovery/etc tools. It even still has some games (Frozen Bubble, etc) on it. They may help you recover something workable off the image you copied over with dd-rescue. Of course, since they have a bunch of programs, including AV and other MS Windows recovery stuff (there's a nice MS eXPrivacy password blanker utility on there, my boss ran into trouble, hadn't created a password reset disk, and I had to use it on his box, yes, it was his), and network troubleshooting stuff as well, you'll probably want to grab them and play around with them a bit to see what they are like, before actually starting to work on recovering your data. Hope that's useful. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list