On 11/09/2013 04:09 AM, darkestkhan wrote:
> Funny thing (actually not so) - my optic drive is dead. But why do I
> have to reboot
> into recovery mode? System itself works correctly - /boot is on sda2
> and everything
> else is on LVM at sda3
If I understand you correctly that you can boot and use your system without
using the affected drive, then you don't need to boot from alternate media
to troubleshoot the filesystem; but I would still recommend it (can you boot
from a USB flash drive?). If you must boot from the installed distro, it
might be better to boot in single-user ("recovery") mode. The reason for
this is that most distributions are configured to automatically access
drives and filesystems, if only to probe them to determine what filesystems
are available. In general, when troubleshooting filesystems and hard
drives, it's best only to access them in a very controlled way. But please
consider using a live boot distribution that is specifically tailored for
this kind of work, such as parted magic, system rescue cd, etc.
You haven't given enough information, so it's hard to say for sure what is
the problem, forcing us to speculate heavily. You should definitely check
the SMART data on the drive (use smartmontools package) to determine the
status of the drive hardware. The output of dumpe2fs will be helpful. Also
check your _entire_ kernel log, looking for any ATA or other errors that
would indicate drive/controller failures, as well as filesystem messages.
Nonetheless, there are 3 main possibilities:
A. hardware failure: your drive is hosed; there are a number of
sub-possibilities here: controller, cable, drive's controller card, drive
platter surface, drive head, etc.
B. software failure: the drive is working fine but somehow the data on it
became corrupted, either due to a bug in the filesystem software, through a
user-induced error such as writing to /dev/sdX, system crash, or some other
possibilities.
C. The filesystem is fine but you aren't mounting it correctly. Are you
sure that you created an ext* filesystem and not some other kind? Try using
mount without -t. Are you sure that you're mounting the right device file?
The right partition?
You will treat the A and B cases differently: if it's (A), I recommend
*against* trying to recover any data in-place as has been suggested in some
other posts here. Running fsck on a dying drive can make the situation
worse (if you do it anyhow, try using the -c option as suggested elsewhere).
You should rather make an image of the drive; you need some spare space on
which to make the image. You can use something as simple as dd, but if you
encounter hardware errors while reading, try something like ddrescue. If
you still have no luck, you can move the drive to a different machine or
even replace its on-drive controller card with one from an _identical_ model
-- I have successfully done this but it is difficult and not recommended
unless you have some _very_ valuable data on that drive.
>From then on, you can treat (A) and (B) more or less the same: you might use
fsck, debugfs, etc. on the filesystem, but before modifying it, you might
want to make a copy image [in case (A) a copy of the copy] before modifying
it -- or you might just run the tools in-place. Hard to say with the
information you've provided, but from the sounds of it you may not have much
luck -- your filesystem sounds pretty sick.
If that's the case, you'll want to recover the contents rather than the
filesystem; tools like PhotoRec, foremost, scalpel [fork of foremost], etc.
will usually recover some of your files. Lots of options here:
http://www.forensicswiki.org/wiki/Tools:Data_Recovery
I should mention that in case (B) [no hardware failure], if you just want to
jump to recovering the contents rather than the filesystem, it's not
critical to make a copy image; you can just recover straight from the hard
drive.
Good luck,
-- David
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527e4ce8.4020...@meta-dynamic.com
