Hello everyone. I'm new here, but have been using Linux for quite some time. I returned from the beach this past weekend to find my basement server in an unusable state. The HDD light was solid and the machine was unresponsive. I never do this considering my linux box doesn't really ever crash, but I had to do a hard power off.

I attempted to reboot the machine, but it doesn't get very far. Grub loads, and the kernel starts, but this hard drive error immediately begin spewing. It sounds really bad to me.

ata1.01 : status { DRDY ERR}
ata1.01: BDMA stat 0x64
ata1.01: failed command: READ DMA
end_request i/o error, dev sdb, sector 2451
Buffer i/o error on device dm-0, logical block 2

I opted to test out the LVM way of partition management which seems like a terrible idea now. It sounded need to have a single volume group which represents both drives, but I'm having some serious regrets. It seems like I have a bad sector. How do i go about fixing this with lvm in play?

I did a good bit of research and have booted from a cd to attempt rescue. I've issued some commands such as lvm pvscan, lvm vgscan, vgchange -ay, and ran fsck on the volumes. Something is damaged that prevents the root volume from showing up, so I can't run fsck on it. I was hoping to be able to do a dd copy to a new disk, but this machine is old and I can't find any PATA interface drives. The drive is only a couple years old though

I've read that running fsck on the physical drive using lvm is dangerous. Is this true? Suggestions?

Most of my data is safe on this server. I back it up to an external drive. It's really just a tinkering machine in my basement, but I found out the hard way that the mysql databases are living on the root partition. I'd really like to recover those if possible. I've been building a test site on the drupal platform and my db backup is a week old.

This is a hardware error and there is no way to fix that. Since you have a backup I wouldn't spent much time on that, just replace the disk.

Not quite what I was hoping I feel like a bear who's crawled out of hibernation. Parallel ATA drives are nowhere to be found. I guess that I'll have to drop down to using a single drive and do a fresh install. I have 2 500gb, and was using up maybe half of one. This drive is barely 2 years old, so maybe under warranty. It stinks that I'll lose my latest photo gallery and drupal demo databases that weren't backed up. At least the Drupal one was from a week ago and the gallery one was a couple months ago. Smart enough to know about cron... dumb enough not to make full use of it I'm still looking for a hail mary here. whataya got?

It may be possible to use ddrescue to make an image to an external device, so that you can make recovery attempts on the image-file.
Other than that I can only say: Now hopefully you will implement a proper backup strategy. Such mistakes usually are made only once. I had the same with an about six months old disk and since then I know how important a good backup plan is.

I ran ddrescue last night and came up with an image of the drive with everything except 4096 bytes. I guess next I'll need to figure out which file(s) lives in the damaged area sector and try to repair the image if it's important. I used the SystemRescueCD project to run ddrescue.

root@debian /mnt/external % ddrescue /dev/sdc /mnt/external/hdimagefile logfile


Press Ctrl-C to interrupt
rescued: 500107 MB, errsize: 4096 B, current rate: 0 B/s
ipos: 1256 kB, errors: 1, average rate: 36284 kB/s
opos: 1256 kB, time from last successful read: 1.6 m
Finished

# Rescue Logfile. Created by GNU ddrescue version 1.15
# Command line: ddrescue /dev/sdc /mnt/external/hdimagefile logfile
# current_pos current_status
0x00132C00 +
# pos size status
0x00000000 0x00132000 +
0x00132000 0x00001000 -
0x00133000 0x7470AD3000 +

http://grover.open2space.com/content...rive-partition

I found this tidbit of gold from someone else who had to recover data from a corrupted lvm partition.
With LVM
If the partition you are trying to recover data from is an LVM partition, then the process is different. First, you need to have the LVM management tools installed, which may mean a change to the kernel. I would also recommend disconnecting the suspect drive before continuing - just to avoid any inadvertent changes to it.

Here is the process in summary, and we'll discuss the commands below:

view sourceprint?
1.losetup -a
2.losetup /dev/loop2 /the/image/file
3.vgscan
4.vgchange -a y
5.vgdisplay -v
6.mount -t ext3 /dev/VolGroup00/LogVol01 /the/mount/point•losetup -a - this tells what loop devices are already in use. We need to find a loop device that is NOT in use. (i.e. a number that is not listed).
•losetup /dev/loop2 /the/image/file - this will treat the image file as a loop device, and assign the loop device number (in this sample, it would be loop device 2). Chang the number to be something that is not already running - i.e. /dev/loop5.
•vgscan - the LVM system will scan the devices, including the loop devices, for volumes and report what is there. We want to make sure the volume on the image file is seen.
•vgchange -a y - this will activate the volume(s).
•vgdisplay -v - this will list the known volumes. We are interested in the "LV NAME" value for the suspect partition/volume. We use this value in the mount command.
•mount -t ext3 /dev/VolGroup00/LogVol01 /the/mount/point - this will mount the volume at the given mount point.
At that point you can change into the /the/mount/point directory, and access the files as if the drive was operating fine. The mounting process is the only part that is different for LVM