Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
To start the story off, I was having some issues with my network card which is a 3com 905b. What happens is it does some sort of TX ring pointer thing, which I have no idea why, but it seems to be a common error. Anyway rebooting fixes the problem which I had a terminal opened so I did a sudo shutdown -r now. The computer rebooted and I logged into gnome and saw that my usb drive wasnt mounted on the desktop as usual. after checking dmesg | tail I see:
[ 142.764000] scsi 4:0:0:0: Direct-Access USB 2.0 Storage Device 0111 PQ: 0 ANSI: 0 CCS
[ 142.764000] sd 4:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
[ 142.764000] sd 4:0:0:0: [sda] Write Protect is off
[ 142.764000] sd 4:0:0:0: [sda] Mode Sense: 08 00 00 00
[ 142.764000] sd 4:0:0:0: [sda] Assuming drive cache: write through
[ 142.768000] sd 4:0:0:0: [sda] 312581807 512-byte hardware sectors (160042 MB)
[ 142.768000] sd 4:0:0:0: [sda] Write Protect is off
[ 142.768000] sd 4:0:0:0: [sda] Mode Sense: 08 00 00 00
[ 142.768000] sd 4:0:0:0: [sda] Assuming drive cache: write through
[ 142.768000] sda: sda1
[ 142.784000] sd 4:0:0:0: [sda] Attached SCSI disk
[ 142.784000] sd 4:0:0:0: Attached scsi generic sg1 type 0
[ 143.160000] EXT3-fs error (device sda1): ext3_check_descriptors: Block bitmap for group 384 not in group (block 1792)!
[ 143.168000] EXT3-fs: group descriptors corrupted!
This device has quite a bit of data on it that I would like to keep. Mainly movies that I backed up and video podcasts. I am in need of help so it is much appreciated. One last thing:
jason@blackhawk:~$ fdisk -l /dev/sda1
Disk /dev/sda1: 160.0 GB, 160040992768 bytes
64 heads, 32 sectors/track, 152626 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/sda1 doesn't contain a valid partition table
The ext3 error message indicates some filesystem corruption; the usual cause on external hard drives is disconnecting the device before unmounting the device is complete or hard shutdowns with the device mounted. If you can still read the data on the drive, copy it off there now. If not, you can usually repair the filesystem using the fsck utilities on the drive but there is some risk of data loss and fsck doesn't always work. Here's the man page for fsck:
In your case, I would try fsck with these options:
$ sudo fsck.ext3 -pv /dev/sda1
Make sure sda1 is not mounted before running fsck on it. You should never run fsck on a mounted filesystem.
General observation, the error message you are getting indicates the ext3 superblock can be read so that's a good sign. When the filesystem is really messed up you usually get an error message that the superblock cannot be read or is invalid.
Re your fdisk output, it's probably nothing unless prior to this problem fdisk did not report any problems with the partition table. In that case you have some real problems. I doubt that's the case, because your system is picking up the drive and attempting to mount it as well as giving you a very specific error/inconsistency in your superblock. If the partition table was seriously corrupted, that would probably not happen. It's not uncommon for fdisk to report problems with partitions created by windows partitioning tools and it's usually nothing to worry about.
160EXT: Note: if several inode or block bitmap blocks or part
of the inode table require relocation, you may wish to try
running e2fsck with the '-b 32768' option first. The problem
may lie only with the primary block group descriptors, and
the backup block group descriptors may be OK.
160EXT: Block bitmap for group 384 is not in group. (block 1792)
160EXT: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
This is what I end up with. Any other options? I have a Hirens boot disk. Would that help me in this situation with recovery? I know there are tools on there for data recovery. This drive was also created in linux. This command worries me:
Code:
jason@blackhawk:~$ fdisk -l /dev/sda
Disk /dev/sda: 160.0 GB, 160041884672 bytes
64 heads, 32 sectors/track, 152627 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Disk identifier: 0x76928106
Device Boot Start End Blocks Id System
/dev/sda1 * 1 152627 156290032 e W95 FAT16 (LBA)
This drive is EXT3. Thanks again guys!
Last edited by dtmbmw325i; 01-04-2008 at 03:29 PM.
Well I fixed my issue I believe. I understood the the story behind superblocks being written every certain number of blocks but I didnt know how to get one to work to fix my issue. I then found the command mke2fs -n /dev/sda1 which I believe was the one that listed where every one was written (please correct me if I am wrong). I used the second one in the list in my fsck.ext3 -yb 98304 /dev/sda1 which found a boatload of illegal inodes. It seemed to remove them and now all seems to be working well. The partition remounted and all the data seems to be intact. I hope this can help somebody with possibly just a little bit of doctoring if need be from someone here. I appreciate the help that the fine members of this board provide me with. Thanks a bunch.
Well I fixed my issue I believe. I understood the the story behind superblocks being written every certain number of blocks but I didnt know how to get one to work the list in my fsck.ext3 -yb 98304 /dev/sda1 which found a boatload of illegal inodes. It seemed to remove them and now all seems to be working well. The partition remounted and all the data seems to be intact. I hope this can help somebody with possibly just a little bit of doctoring if need be from someone here. I appreciate the help that the fine members of this board provide me with. Thanks a bunch.
Hello!
Thank you all, and especially dtmbmw325i, I had exact the same problem with my ext2 partition, and I tried many commands, and your concept was the solution. I had too used the second superblock (found by mke2fs -n /dev/hda2) in the list in my
Code:
fsck.ext2 -b 98304 /dev/hda2
Tip: use
Code:
fsck.ext2 -yb 98304 /dev/hda2
NOT
Code:
fsck.ext2 -b 98304 /dev/hda2
if you dont want to answer more than 24000 questions (in a 40GB partition) like me, I kept the 'y' key pressed by laying something heavy on it to avoid aborting the command
I am also fairly new at this and have quite the same problem. Only my external hdd has a fat32 filesystem. I've been trying for several days now and with info from this forum to get my drive working again, but so far nothing :s hopefully you can help me out with this:
ubuntu@ubuntu:~$ sudo fsck.ext3 -pv /dev/sdd
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdd
/dev/sdd:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
A new thread would help you by providing more exposure.
To perform the fsck you should not have the filesystem mounted. You can boot to a single user mode or from your install media then perform the maintenance on the filesystem. You need to be in single user mode so that security of no one else using the filesystem.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.