Announcement

**doctordruidphd** · Dec 01, 2011, 09:09 PM

Re: external usb disk won't mount, error

Not sure about on 8.04, can you try mounting this on a more recent release?

If it still doesn't work, the command to scan and fix the file system is:

sudo e2fsck /dev/sdb1

The file system must be unmounted before doing this.

Ideally you want a backup before doing this, but if the drive is corrupted, you may not be able to do that. You can lose data this way, so be forewarned. The only other option I know of to get data off the disk is to go with forensic tools like photorec or testdisk.

Filling to 99% is probably not a good idea. I don't klnow exactly how much space is needed for housekeeping, but probably more than 1%. So you may have run into problems with too little space.

**Telengard** · Dec 01, 2011, 09:58 PM

Re: external usb disk won't mount, error

Originally posted by doctordruidphd

Not sure about on 8.04, can you try mounting this on a more recent release?

I can, although I don't know why that would matter. I've got Lucid on one computer and Karmic on another. I'll try plugging into the Lucid computer tomorrow, just to see what happens.

sudo e2fsck /dev/sdb1

Ideally you want a backup before doing this, but if the drive is corrupted, you may not be able to do that. You can lose data this way, so be forewarned.

Damn straight I want a backup before writing anything to the disk! Is there a version of dd which will raw-read the whole partition into an archive? I'm pretty sure partimage won't do anything with a corrupted FS.

(OT: Sad thing is, this was going to be a backup disk, but I ended up using it as a staging area for shuffling things around while I save $$$ for a new HD.)

The only other option I know of to get data off the disk is to go with forensic tools like photorec or testdisk.

I'm praying I don't have to go that route. So time consuming!

Filling to 99% is probably not a good idea. I don't klnow exactly how much space is needed for housekeeping, but probably more than 1%. So you may have run into problems with too little space.

I never tuned the FS after formatting (actually I never do). EXT usually reserves 10% (I think) of the volume for overhead of some kind.

Tomorrow there'll be a backhoe digging up my front yard. Dunno how much time I'll have to mess with this until the weekend.

Thanks for the reply

**doctordruidphd** · Dec 02, 2011, 08:34 AM

Re: external usb disk won't mount, error

Is there a version of dd which will raw-read the whole partition into an archive

Any version of dd should do this -- dd reads by sector, not by file. So it will merrily copy whatever is on the disk -- corrupted descriptors and all -- and copy it as is to something else. So if you use dd, be ready for the fact that whatever you copy to will also be corrupted. But as I said, you may be able to get data off of it by truly tedious but effective forensic means.. Tesdisk may be the best option.

**Telengard** · Dec 02, 2011, 10:19 AM

Re: external usb disk won't mount, error

Originally posted by doctordruidphd

Any version of dd should do this -- dd reads by sector, not by file.

Good point! Looks like dd defaults to targeting STDOUT. So I should be able to do something like this, right?

Code:

#save partition data to archive
dd -if=/dev/sdb1 | tar -cf /mnt/backup-disk/disk-archive.tar

#extract partition data from archive
tar -xf /mnt/backup-disk/disk-archive.tar | dd -of=/dev/sdb1

I don't know if that syntax will work as is. Do you think I'm getting close? (Will be researching this today.)

So it will merrily copy whatever is on the disk -- corrupted descriptors and all -- and copy it as is to something else. So if you use dd, be ready for the fact that whatever you copy to will also be corrupted.

I think the dd command above will make a perfect byte-for-byte image of the partition in its current state, corrupted filesystem and all. So if fsck or testdisk makes a mess, I can extract the image to the partition and get it back to the state it is right now.

But as I said, you may be able to get data off of it by truly tedious but effective forensic means.. Tesdisk may be the best option.

The most tedious way possible would be knitting the filesystem back together by hand with a disk editor. Been there, done that, don't wanna ever do it again. photorec and foremost can partially automate the process, but complex job is still pretty complex.

Before doing anything else, I think I should eliminate any possible trouble from the enclosure. May be a good idea to remove the disk from the enclosure and attached to the slave connector of the primary IDE channel.

**dibl** · Dec 02, 2011, 10:36 AM

Re: external usb disk won't mount, error

I have very thin dd experience, however one error that I see is the hyphen before "if" -- it is not needed. Qqmike wrote a nice dd guide here.

I'm pretty sure that all dd commands have to take the form of "if > of" -- the Input File goes in, and the Output File comes out of it.

**Telengard** · Dec 02, 2011, 11:35 AM

Re: external usb disk won't mount, error

Originally posted by dibl

. . . the hyphen before "if" -- it is not needed.

Right, see that now that I'm reading the documentation. The if= and of= bits are not options; they are called operands.

Qqmike wrote a nice dd guide here.

Will read. TYVM

I'm pretty sure that all dd commands have to take the form of "if > of" -- the Input File goes in, and the Output File comes out of it.

Not sure that's exactly right, but here's what the docs say about the default mode of dd.

Originally posted by info coreutils 'dd invocation'

copies a file (from standard input to standard output, by default)

I should be able to dd any binary data to a pipe into any command I like. Here's a quick test of that theory.

Code:

$ dd if=/usr/share/doc/bash/README.commands.gz | gunzip | head
5+1 records in
5+1 records out
3037 bytes (3.0 kB) copied, 5.9713e-05 s, 50.9 MB/s
  This is a jumping-off reference point for new users who may be
  completely unfamiliar with Linux commands. It does not contain all
  the information you need about using the Linux console, but instead
  just gives you enough information to get started finding the
  information you need.

Linux Commands

  To run a command, type the command at the prompt, followed by any
  necessary options, and then press the Enter or Return key.

The compressed data was copied verbatim, as demonstrated by the fact that gunzip was able to unpack the archive from its STDIN to its STDOUT. Time to read more.

**doctordruidphd** · Dec 02, 2011, 02:52 PM

Re: external usb disk won't mount, error

Yeah, I think with a corrupted file system, dd is probably the only way to back it up. I don't know what it will do if it finds a bad sector, but if the problem is file system structure, it will just copy it.
Then it's up to e2fsck. Your original post came through on my browser that you made the file system as ext[23]. Well, it's one or the other, 2 or 3, not both. If it's 3, then it may just read the journal and fix the system. But if it's 2, there is no journal, and it will have to fix it the long way. Might work, though, if all the planets are aligned auspiciously.

**Telengard** · Dec 02, 2011, 07:48 PM

Re: external usb disk won't mount, error

Originally posted by doctordruidphd

Yeah, I think with a corrupted file system, dd is probably the only way to back it up.

I'm sure there are some other tools. There is something called ddrescue that I haven't looked into, just as an example.

I don't know what it will do if it finds a bad sector, but if the problem is file system structure, it will just copy it.

Here's what I've gotten from my reading so far. If an error occurs while reading the input file dd will quit, unless you pass it the conv=noerror operand. You're right about filesystem corruption: dd doesn't care because it is just reading raw bytes from a file.

Your original post came through on my browser that you made the file system as ext[23]. Well, it's one or the other, 2 or 3, not both.

Sorry for the confusion. I don't remember which filesystem I made on the disk, so I got cute and wrote it as a regular expression; yeah, that's a character list :P

Code:

$ dmesg | tail | grep 'sdb1'
[ 691.884348] EXT2-fs error (device sdb1): ext2_check_descriptors: Block bitmap for group 1152 not in group (block 4294967288)!
$ sudo parted /dev/sdb print

Disk /dev/sdb: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start  End  Size  Type   File system Flags
 1   32.3kB 160GB 160GB primary ext2

Looks like it must be ext2.

But if it's 2, there is no journal, and it will have to fix it the long way. Might work, though, if all the planets are aligned auspiciously.

Doh! >

Originally posted by doctordruidphd

Not sure about on 8.04, can you try mounting this on a more recent release?

Tried plugging into the USB on my 10.04 Lucid system. Got a Dolphin window with a similar error, and the drive failed to mount

NOTE: open the attachment snapshot18.png for a picture of this error

I have removed the HD from the enclosure. It is now attached to the slave connector on this computer's primary IDE cable. When I try mounting it I get the same error.

Back to reading up on dd.

Attached Files

**doctordruidphd** · Dec 02, 2011, 08:51 PM

Re: external usb disk won't mount, error

Well, I can't figure out how to quote the image, but the message about "bad superblock" may be good news in disguise.

Check the e2fsck man page, and particularly the -b option.

Apparently you can run e2fsck with the -n option, which will open it as read only, and just do diagnostics.

You can get some info about the file system on the disk with:

sudo dumpe2fs -h /dev/sdb1

This will dump a couple screenfuls, but among that will be the "block size" parameter.

(check man dumpe2fs for more info on this command)

Edit: careful looks like the -n option might not really be read-only.

So it might be worth trying it with something like
sudo e2fsck -n -b 4097
or whatever value for the "4097" is appropriate (experiment) and see if it will fly.
Check the /etc/mke2fs.conf file for the default block size on the system you used to create the file system. (8.04)

Sorry for the stream-of-consciousness here, but I'm in something of a manpage loop going through these commands.

**Telengard** · Dec 03, 2011, 01:01 AM

Re: external usb disk won't mount, error

Currently imaging the partition to a file on a network share.

Code:

sudo dd if=/dev/sdb1 of=/mnt/backups/stew/sdb1.dd bs=4k conv=noerror,notrunc

Thanks QQmike

**Telengard** · Dec 03, 2011, 01:57 PM

Re: external usb disk won't mount, error

Next morning I see this:

Code:

tmp$ sudo dd if=/dev/sdb1 of=/mnt/backups/stew/sdb1.dd bs=4k conv=noerror,notrunc
39062039+1 records in
39062039+1 records out
159998114304 bytes (160 GB) copied, 14193.6 s, 11.3 MB/s

Looks like there were no bad blocks encountered! If dd conv=noerror encounters errors reading the input file it should report them to STDERR and then continue reading, correct? So only the filesystem is damaged; the partition itself is fine.

Now to protect sdb1.dd from me doing stupid things:

Code:

$ cd /mnt/backups/
backups$ chmod -Rv '-w' stew
mode of `stew' changed to 0555 (r-xr-xr-x)
mode of `stew/sdb1.dd' changed to 0444 (r--r--r--)

Originally posted by doctordruidphd

. . . the message about "bad superblock" may be good news in disguise. Check the e2fsck man page, and particularly the -b option.

Originally posted by man e2fsck

. . .
-b superblock
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.
Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary superblock is updated appropriately upon completion of the filesystem check.
. . .

I need to do much more reading before trying something like that.

Originally posted by doctordruidphd

Apparently you can run e2fsck with the -n option, which will open it as read only, and just do diagnostics.
. . .
Edit: careful looks like the -n option might not really be read-only.

Originally posted by man e2fsck

Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified.
. . .
-n
Open the filesystem read-only, and assume an answer of `no' to all questions. Allows e2fsck to be used non-interactively. (Note: if the -c, -l, or -L options are specified in addition to the -n option, then the filesystem will be opened read-write, to permit the bad-blocks list to be updated. However, no other changes will be made to the filesystem.) This option may not be specified at the same time as the -p or -y options.
. . .

-c = find bad blocks and add them to bad block inode
-l file = update bad blocks list from list in file
-L file = clear bad blocks list and then add bad blocks from list in file

Since dd didn't report any errors while reading /dev/sdb1, I don't believe I need to do anything about bad blocks. With that in mind, I don't plan to use any of the three options listed above, so calling e2fsck -n should not cause any writing to the disk. Is that right?

Also interesting:

Originally posted by man e2fsck

-p
Automatically repair ("preen") the file system. This option will case e2fsck to automatically fix any filesystem problems that can be safely fixed without human intervention. If e2fsck discovers a problem which may require the system administrator to take additional corrective action, e2fsck will print a description of the problem and then exit with the value 4 logically or'ed into the exit code. (See the EXIT CODE section.) This option is normally used by the system's boot scripts. It may not be specified at the same time as the -n or -y options.

Originally posted by doctordruidphd

You can get some info about the file system on the disk with:

sudo dumpe2fs -h /dev/sdb1

This will dump a couple screenfuls, but among that will be the "block size" parameter.

(check man dumpe2fs for more info on this command)

Originally posted by man dumpe2fs

. . .
dumpe2fs prints the super block and blocks group information for the filesystem present on device.
. . .
-h
only display the superblock information and not any of the block group descriptor detail information.
-i
display the filesystem data from an image file created by e2image, using device as the pathname to the image file.

Seems pretty straightforward. (Hmm ... maybe I could have used the e2image program instead of dd?). Let's give it a go:

Code:

tmp$ sudo dumpe2fs -h /dev/sdb1
dumpe2fs 1.40.8 (13-Mar-2008)
Filesystem volume name:  <none>
Last mounted on:     <not available>
Filesystem UUID:     aafa5609-5eeb-4d9f-bdad-abbbfa1742bb
Filesystem magic number: 0xEF53
Filesystem revision #:  1 (dynamic)
Filesystem features:   filetype sparse_super
Default mount options:  (none)
Filesystem state:     clean with errors
Errors behavior:     Continue
Filesystem OS type:    Linux
Inode count:       19546112
Block count:       39062039
Reserved block count:   1953101
Free blocks:       2560443
Free inodes:       19285281
First block:       0
Block size:        4096
Fragment size:      4096
Blocks per group:     32768
Fragments per group:   32768
Inodes per group:     16384
Inode blocks per group:  512
Last mount time:     Sun Nov 6 16:14:15 2011
Last write time:     Fri Dec 2 19:49:56 2011
Mount count:       5
Maximum mount count:   30
Last checked:       Wed Dec 31 19:00:00 1969
Check interval:      0 (<none>)
Reserved blocks uid:   0 (user root)
Reserved blocks gid:   0 (group root)
First inode:       11
Inode size:        128

tmp$

Interesting items, my comments in parentheses:

Filesystem state: clean with errors ( hmm!)
Block size: 4096 (as expected)
Last mount time: Sun Nov 6 16:14:15 2011 (seems right)
Last write time: Fri Dec 2 19:49:56 2011 ( I didn't write anything to the disk yesterday, but I did attempt to mount it!)
Last checked: Wed Dec 31 19:00:00 1969 ( WTF!?!)

Originally posted by doctordruidphd

So it might be worth trying it with something like
sudo e2fsck -n -b 4097
or whatever value for the "4097" is appropriate (experiment) and see if it will fly.

Well ... 4096 is a power of two, and more like what I'd expect for block size on modern filesystems. Is that what you meant?

Originally posted by doctordruidphd

Check the /etc/mke2fs.conf file for the default block size on the system you used to create the file system. (8.04)

I partitioned and formatted the drive with parted interactively. Does parted use mke2fs.conf when calling mke2fs? Does parted supply its own defaults to mke2fs?

On the system which partitioned and formatted the drive using parted (8.04 Hardy):

Code:

tmp$ cat /etc/mke2fs.conf
[defaults]
    base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
    blocksize = 4096
    inode_size = 128
    inode_ratio = 16384

[fs_types]
    small = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 4096
    }
    floppy = {
        blocksize = 1024
        inode_size = 128
        inode_ratio = 8192
    }
    news = {
        inode_ratio = 4096
    }
    largefile = {
        inode_ratio = 1048576
    }
    largefile4 = {
        inode_ratio = 4194304
    }
tmp$

I'm going to look more into what arguments to pass e2fsck later today. Further comments, corrections, and advice gratefully welcomed!

**doctordruidphd** · Dec 03, 2011, 03:35 PM

Re: external usb disk won't mount, error

OK, after looking at all that, the

Filesystem state: clean with errors

part says to me it's ready for e2fsck. Especially since you have a backup.

re the 4097 -- since it's 4096 block sixe, my guess is the next block starts at 4097 -- but maybe not, if the first block is 0. I'm basing that on the example that is from an 8k block size, and uses 8k+1. dumpe3fs has already said your system is 4k block size.
Maybe that whole mess is unnecessary, if e2fsck does what it is supposed to do.

I would just go ahead with the -n option, and see what happens. That's why you have the backup. dunno about

Does parted use mke2fs.conf when calling mke2fs?

I think pretty much all of the file system create tools do.

I have a feeling that whatever e2image is going to save, is probably the corrupted part.

Edit: if you want to do even more research, look at debugfs. I don't have a borked filesystem to try it on, so I don't know if it will do anything useful.

**Telengard** · Dec 03, 2011, 05:28 PM

Re: external usb disk won't mount, error

Originally posted by doctordruidphd

I would just go ahead with the -n option, and see what happens.

Code:

tmp$ sudo e2fsck -n /dev/sdb1
e2fsck 1.40.8 (13-Mar-2008)
e2fsck: Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

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>

tmp$

Back to reading ...

**Telengard** · Dec 03, 2011, 06:39 PM

Re: external usb disk won't mount, error

Talk about flow of consciousness, doin' The Manpage Mambo ...

Originally posted by man e2fsck

. . .
-b superblock
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.
Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary superblock is updated appropriately upon completion of the filesystem check.
-B blocksize
Normally, e2fsck will search for the superblock at various different block sizes in an attempt to find the appropriate block size. This search can be fooled in some cases. This option forces e2fsck to only try locating the superblock at a particular blocksize. If the superblock is not found, e2fsck will terminate with a fatal error.

1. Should I use e2fsck -b 32768? dumpe2fs reported block size is 4096.
2. Are backup superblocks exact copies of the primary superblock? I don't want my FS reverted to a previous state. I want to go back to how it was before the last write was committed (presuming that's when the corruption occurred.)
3. Should I try e2fsck -B 4096? How would this be different than specifying a superblock with -b?

Lets see what mke2fs has to say about the suggested options.

Originally posted by man mke2fs

. . .
-b block-size
Specify the size of blocks in bytes. Valid block size vales are 1024, 2048 and 4096 bytes per block. If omitted, mke2fs block-size is heuristically determined by the file system size and the expected usage of the filesystem (see the -T option). If block-size is negative, then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes. This is useful for certain hardware devices which require that the blocksize be a multiple of 2k.
. . .
-n
causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem. This can be used to determine the location of the backup superblocks for a particular filesystem, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again.
. . .

Trying mke2fs without specifying a blocksize:

Code:

tmp$ sudo mke2fs -n /dev/sdb1
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
9773056 inodes, 39062039 blocks
1953101 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Now with a blocksize:

Code:

tmp$ sudo mke2fs -b 4096 -n /dev/sdb1
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
9773056 inodes, 39062039 blocks
1953101 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Same output. I'm just about ready to assume that the superblock list shown above is correct for my FS.

I'll break here for now, whilst I read more manpages

Announcement

[solved with recent e2fsck] external usb disk won't mount, error

[solved with recent e2fsck] external usb disk won't mount, error

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment