mountiing a ext3 disk (Ubuntu 7.04)

Try editing the fstab file to look like this.

/dev/sdc1 /data1 ext3 defaults 0 2

I forget the details with the numbers at the end but you seem to be missing the last one. I think 1 is for main and 2 is for all others or something like that.

Thanks but it didn't work. Still the same error message.

jbellido@pierre:~$ sudo mount -a
Password:
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

jbellido@pierre:~$ more /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=64758fd5-e77e-4262-8ed0-fe017d91b188 / ext3 defaults,error
s=remount-ro 0 1
# /dev/sda5
UUID=4fb623f9-a74a-4f54-a87d-ab836c53c19f none swap sw
  0 0
/dev/scd1 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/scd0 /media/cdrom1 udf,iso9660 user,noauto 0 0
/dev/sdb1 /data0 ext3 defaults 0 2
/dev/sdc1 /data1 ext3 defaults 0 2

Hmmm, it shouldn't make any difference where you mount them but does data0 and data1 exist? Usually you have to create the mount point before anything can be mounted there. I might move them to the /media dir so do something like

sudo mkdir /media/data0
sudo mkdir /media/data1

and then change fstab to

/dev/sdc1 /media/data1 ext3 defaults 0 2

Of course, if you did create the data0 and data1 mount points this is likely to make much difference. It would be a bit more conventional though.

If that doesn't work either then I'm not sure what else to offer. Are the drives in question formatted and all? If they are new drives they may need formatting first. Just grasping at straws now, sorry.

I found that the problem is that the disk wasn't cleanly unmounted. I am trying to use e2fsck to fix this problem.

This may be too late, but you can use the tune2fs command to read the contents of the superblock of an ext2/3 filesystem and see what state it's in. For example:

sudo tune2fs -l /dev/sdb1
sudo tune2fs -l /dev/sdc1

This should output a lot of information, hopefully, but you should look at the line that reports filesystem state, and after the recovery, it should look like this:

Filesystem state: clean

Hope this helps!

Hi Rouben,

   I am still strugling with these two data disks.

  I tried your suggestion and this is what I got:

jbellido@pierre:~$ sudo tune2fs -l /dev/sdb1
tune2fs 1.40-WIP (14-Nov-2006)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

   How do I find the volume label or the UUID of the disks? Perhaps if I
use them instead of the device name?

   Thanks

Jose

On Tue, 31 Jul 2007, Rouben wrote:

> Your question #10671 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/10671
>
> Status: Open => Needs information
>
> Rouben requested for more information:
> This may be too late, but you can use the tune2fs command to read the
> contents of the superblock of an ext2/3 filesystem and see what state
> it's in. For example:
>
> sudo tune2fs -l /dev/sdb1
> sudo tune2fs -l /dev/sdc1
>
> This should output a lot of information, hopefully, but you should look
> at the line that reports filesystem state, and after the recovery, it
> should look like this:
>
> Filesystem state: clean
>
> Hope this helps!
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.launchpad.net/ubuntu/+question/10671
>
> You received this question notification because you are a direct
> subscriber of the question.
>

To find the UUID open a terminal and do

sudo vol_id -u device

where device is the name of the partition such as /dev/sda1

However, I've found UUIDs more trouble than device names but it might help.

Using UUIDs vs. device names won't really help, since UUID references are typically just symbolic links to the actual device names, so really you're referencing exactly the same special device file.

Are you absolutely sure these are ext3 partitions? If so, they may be really badly corrupted... Your only hope may be running fsck.ext3 on them. More about that later... before we try fsck, let's make sure that these are indeed ext3 partitions... Try using the file command to determine that:

sudo file -s /dev/sdb1
sudo file -s /dev/sdc1

If these are indeed normal ext3 partitions, you should see something like this:
/dev/sdb1: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)

Note that since the filesystem is probably corrupted, you may not see the above exactly, however, hopefully file will make enough sense of the partition to tell you at least roughly what's inside. Once you establish that this is indeed an ext3 partition, you can try using fsck.ext3. I repeat, do NOT run this unless you are absolutely sure that this is an ext3 partition; you may permanently destroy all data on this partition if it's not ext3!!!

sudo /sbin/fsck.ext3 -cc -f -v -y /dev/sdb1
sudo /sbin/fsck.ext3 -cc -f -v -y /dev/sdb1

Now to explain each option (read man fsck.ext3 for details):
-cc: Do a non-destructive block-level read-write test to make sure the disk surface is free of physical defects. Attempt to move any data off defective disk surface areas if necessary. This will not destroy the data on disk (i.e. non-destructive read-write test), unless the disk is completely hosed.
-f: force checking the partition even if it seems to be OK (normally if fsck thinks that the partition doesn't need to be checked, it will just abort)
-v: verbose mode (fsck will be talkative)
-y: assume "yes" to all questions, which are typically "do you want to repair problem X (y/n)?". This option may seem similar to -p (which means "automatically fix all problems), but it's actually more "powerful", in other words, when -p is used and fsck finds that your filesystem is badly broken, it will abort. However, fsck will never abort checking the filesystem if -y was used.

Again, ONLY run fsck if you are absolutely, positively, 200% sure that you are dealing with ext3 partitions.

I think the initial problem with the disk was that they were previously
mounted using LVM tools. It seems that it had a physical Volume created
containing the disk mounting information, So I should have used LVM tools
to find the Volume name and mount it.

  I am afraid that after trying to fix a "corrrupted" disk I may have lost
the data on the disks.

  I have typed:

>sudo mke2fs -S /dev/sdc1 (this created an ext3 fs)
>sudo mke2fs -j /dev/sdc1 (this created a journal)

  after these two commands I could mount the disks but I couldn't see any
of the data. There only was the directory /lostfound

  thanks,

Jose

On Wed, 1 Aug 2007, Rouben wrote:

> Your question #10671 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/10671
>
> Rouben requested for more information:
> Using UUIDs vs. device names won't really help, since UUID references
> are typically just symbolic links to the actual device names, so really
> you're referencing exactly the same special device file.
>
> Are you absolutely sure these are ext3 partitions? If so, they may be
> really badly corrupted... Your only hope may be running fsck.ext3 on
> them. More about that later... before we try fsck, let's make sure that
> these are indeed ext3 partitions... Try using the file command to
> determine that:
>
> sudo file -s /dev/sdb1
> sudo file -s /dev/sdc1
>
> If these are indeed normal ext3 partitions, you should see something like this:
> /dev/sdb1: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)
>
> Note that since the filesystem is probably corrupted, you may not see
> the above exactly, however, hopefully file will make enough sense of the
> partition to tell you at least roughly what's inside. Once you establish
> that this is indeed an ext3 partition, you can try using fsck.ext3. I
> repeat, do NOT run this unless you are absolutely sure that this is an
> ext3 partition; you may permanently destroy all data on this partition
> if it's not ext3!!!
>
> sudo /sbin/fsck.ext3 -cc -f -v -y /dev/sdb1
> sudo /sbin/fsck.ext3 -cc -f -v -y /dev/sdb1
>
> Now to explain each option (read man fsck.ext3 for details):
> -cc: Do a non-destructive block-level read-write test to make sure the disk surface is free of physical defects. Attempt to move any data off defective disk surface areas if necessary. This will not destroy the data on disk (i.e. non-destructive read-write test), unless the disk is completely hosed.
> -f: force checking the partition even if it seems to be OK (normally if fsck thinks that the partition doesn't need to be checked, it will just abort)
> -v: verbose mode (fsck will be talkative)
> -y: assume "yes" to all questions, which are typically "do you want to repair problem X (y/n)?". This option may seem similar to -p (which means "automatically fix all problems), but it's actually more "powerful", in other words, when -p is used and fsck finds that your filesystem is badly broken, it will abort. However, fsck will never abort checking the filesystem if -y was used.
>
> Again, ONLY run fsck if you are absolutely, positively, 200% sure that
> you are dealing with ext3 partitions.
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.launchpad.net/ubuntu/+question/10671
>
> You received this question notification because you are a direct
> subscriber of the question.
>

If you have already run mke2fs on these disks, then you have reformatted them in Microsoft terms. I can't think of any way to recover the data off them... sorry! :(

Hello!

Sorry for renewing this old discussion, but it seems I may have similar problem:
My outputs:

mount -t ext3 /dev/sda6 /media/storage/
mount: wrong fs type, bad option, bad superblock on /dev/sda6,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

lspci -v
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master])
 Subsystem: Dell Device 0188
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
 I/O ports at 01f0 [size=8]
 I/O ports at 03f4 [size=1]
 I/O ports at 0170 [size=8]
 I/O ports at 0374 [size=1]
 I/O ports at bfa0 [size=16]
 Capabilities: [70] Power Management version 2
 Kernel driver in use: ata_piix
 Kernel modules: ata_piix, ahci

tune2fs -l /dev/sda6
tune2fs 1.41.8 (11-July-2009)
tune2fs: Bad magic number in super-block while trying to open /dev/sda6
Couldn't find valid filesystem superblock.

fdisk /dev/sda

The number of cylinders for this disk is set to 12161.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xffff6a42

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 10 80293+ 83 Linux
/dev/sda2 11 40 240975 82 Linux swap / Solaris
/dev/sda3 41 12161 97361932+ 5 Extended
/dev/sda5 41 8000 63938668+ 83 Linux
/dev/sda6 8001 12161 33423232 83 Linux

file -s /dev/sda6
/dev/sda6: data

fsck.ext3 -cc -f -v /dev/sda6
e2fsck 1.41.8 (11-July-2009)
fsck.ext3: Superblock invalid, trying backup blocks...
fsck.ext3: Bad magic number in super-block while trying to open /dev/sda6

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>

Thanks!

Luke