Re: Lost HD Partition

Re: Lost HD Partition

[Peter]

Thanks all!

mount  -t ext2 /dev/hda6 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/hda6,
       missing codepage or other error
      

Yes I am sure that the partition was formated as ext3, then this does 
not work according to Chuck since these filesystems depend on the 
superblock.

Trying Hal's suggestion:

/sbin/e2fsck -b 32768 /dev/hda6
e2fsck 1.38 (30-Jun-2005)
/sbin/e2fsck: Invalid argument while trying to open /dev/hda6

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>


/sbin/mke2fs -n /dev/hda6

mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
244320 inodes, 487966 blocks
24398 blocks (5.00%) reserved for the super user
First data block=0
15 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Trying these backup superblocks /sbin/e2fsck -b * /dev/hda6, I get with 
each: Invalid argument while trying to open /dev/hda6

Since apparently the superblock is corrupted and the partion has not 
been formated since, therefore the data should still be on the disk.
So what other alternate superblock can be tried?
Yet
The superblock could not be read or does not describe a correct ext2
filesystem.

It seems I am kind of stuck.

Regards

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Lost HD Partition

[Hal MacArgle]

On 06-22, Peter wrote:
> Trying Hal's suggestion:
> 
> /sbin/e2fsck -b 32768 /dev/hda6
> e2fsck 1.38 (30-Jun-2005)
> /sbin/e2fsck: Invalid argument while trying to open /dev/hda6
> 
> 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>
> 
> 
> /sbin/mke2fs -n /dev/hda6
> 
> mke2fs 1.38 (30-Jun-2005)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 244320 inodes, 487966 blocks
> 24398 blocks (5.00%) reserved for the super user
> First data block=0
> 15 block groups
> 32768 blocks per group, 32768 fragments per group
> 16288 inodes per group
> Superblock backups stored on blocks:
>        32768, 98304, 163840, 229376, 294912
> 
> Trying these backup superblocks /sbin/e2fsck -b * /dev/hda6, I get with 
> each: Invalid argument while trying to open /dev/hda6
> 
> Since apparently the superblock is corrupted and the partion has not 
> been formated since, therefore the data should still be on the disk.
> So what other alternate superblock can be tried?
> Yet
> The superblock could not be read or does not describe a correct ext2
> filesystem.
> 
> It seems I am kind of stuck.

	Bummer.. Really grabbing at straws: What might happen if you
booted the machine with a rescue disk that ran a kernel from RAM
then use dd to copy the contents of hda6 to another clean drive
fitted, temporarily, in the machine?? Since hda6 is a virtual
partition, copying it to a primary partition may work?? Depends on
how important that partition is I guess..

	If all those superblock backups are corrupted, it seems
nothing would work though.. I don't think 'sfdisk' will help in this
case either.. Good Luck..

-- 

    Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1   (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Lost HD Partition

[Peter]

For some reason I cannot access my important /usr/local hard drive 
partition.

mount /mnt/hda6
mount: wrong fs type, bad option, bad superblock on /dev/hda6,
missing codepage or other error

# /sbin/fdisk /dev/hda6 -p

Disk /dev/hda6: 1998 MB, 1998710784 bytes
16 heads, 63 sectors/track, 3872 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
----------
The drive has/had ext3 which information apparently got lost

How could I access this drive again and remake it ext3 w/o losing the data?

What other info is needed?

Thanks & regards


Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Lost HD Partition

[Ray Olszewski]

Peter wrote:
> For some reason I cannot access my important /usr/local hard drive 
> partition.
> 
> mount /mnt/hda6
> mount: wrong fs type, bad option, bad superblock on /dev/hda6,
> missing codepage or other error
> 
> # /sbin/fdisk /dev/hda6 -p
> 
> Disk /dev/hda6: 1998 MB, 1998710784 bytes
> 16 heads, 63 sectors/track, 3872 cylinders
> Units = cylinders of 1008 * 512 = 516096 bytes
> 
> Device Boot Start End Blocks Id System
> ----------
> The drive has/had ext3 which information apparently got lost
> 
> How could I access this drive again and remake it ext3 w/o losing the data?
> 
> What other info is needed?
> 
> Thanks & regards

The way you are mounting (or trying to mount) hda6 relies on the 
information about it entered into /etc/fstab . Take a look at that file 
and see if it suggests a solution; if it doesn't, you should probably 
post it here, since one of us might then spot something you missed.

For example, is it possible that fstab specifies the <type> as "ext3" 
rather than as "ext3,ext2"? If so, and if the ext3 journal "got lost" 
somehow (I'm not really clear on what you are telling us happened), then 
the kernel would not try to fall back to ext2 ... offhand, I don't know 
what error it would give, but the one you are seeing at least seems 
consistent with this.

The fdisk information you provide seems a bit sparse. You didn't include 
the partition table info, just what looks like the information about the 
small (by today's standards) physical disk (which would be /dev/hda, not 
/dev/hda6). The combination of that and the fact that my version of 
fdisk doesn't have a -p option leaves me unable to make specific 
suggestions about how you should provide the partition table info.

Have you tried running e2fsck on this partition? If so, what happens?

The usual way to add an ext3 journal to an ext2 filesystem is with 
tune2fs ... specifically, "tune2fs -j /dev/hda6".

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Lost HD Partition

[Peter]

Ray Olszewski wrote:
> Peter wrote:
>> For some reason I cannot access my important /usr/local hard drive 
>> partition.
>>
>> mount /mnt/hda6
>> mount: wrong fs type, bad option, bad superblock on /dev/hda6,
>> missing codepage or other error
>>
>> # /sbin/fdisk /dev/hda6 -p
>>
>> Disk /dev/hda6: 1998 MB, 1998710784 bytes
>> 16 heads, 63 sectors/track, 3872 cylinders
>> Units = cylinders of 1008 * 512 = 516096 bytes
>>
>> Device Boot Start End Blocks Id System
>> ----------
>> The drive has/had ext3 which information apparently got lost
>>
>> How could I access this drive again and remake it ext3 w/o losing the 
>> data?
>>
>> What other info is needed?
>>
>> Thanks & regards
>
> The way you are mounting (or trying to mount) hda6 relies on the 
> information about it entered into /etc/fstab . Take a look at that 
> file and see if it suggests a solution; if it doesn't, you should 
> probably post it here, since one of us might then spot something you 
> missed.
>
> For example, is it possible that fstab specifies the <type> as "ext3" 
> rather than as "ext3,ext2"? If so, and if the ext3 journal "got lost" 
> somehow (I'm not really clear on what you are telling us happened), 
> then the kernel would not try to fall back to ext2 ... offhand, I 
> don't know what error it would give, but the one you are seeing at 
> least seems consistent with this.
>
> The fdisk information you provide seems a bit sparse. You didn't 
> include the partition table info, just what looks like the information 
> about the small (by today's standards) physical disk (which would be 
> /dev/hda, not /dev/hda6). The combination of that and the fact that my 
> version of fdisk doesn't have a -p option leaves me unable to make 
> specific suggestions about how you should provide the partition table 
> info.
>
> Have you tried running e2fsck on this partition? If so, what happens?
>
> The usual way to add an ext3 journal to an ext2 filesystem is with 
> tune2fs ... specifically, "tune2fs -j /dev/hda6".
>
>
thanks!

cat /etc/fstab
.....
/dev/hda6 /mnt/hda6 ext3 noauto,users,suid,dev,exec 0 0
.....

fdisk /dev/hda
Disk /dev/hda: 255 heads, 63 sectors, 4998 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 3 00 254  63 1023 254  63 1023   29334690   50958180 05
 5 00 254  63 1023 254  63 1023   23438835    3903795 05
 6 00 254  63 1023 254  63 1023   27342630    3919860 05
 7 00 254  63 1023 254  63 1023   31262490   13671315 05
 8 00 254  63 1023 254  63 1023   44933805    3903795 05
 9 00 254  63 1023 254  63 1023   48837600    2120580 05
10 00   0   0    0   0   0    0          0          0 00

Disk /dev/hda: 41.1 GB, 41110142976 bytes
255 heads, 63 sectors/track, 4998 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        1824    14651248+   c  W95 FAT32 (LBA)
/dev/hda2            1825        1826       16065   83  Linux
/dev/hda3            1827        4998    25479090    5  Extended
/dev/hda5            1827        3285    11719386   83  Linux
/dev/hda6            3286        3528     1951866   83  Linux
/dev/hda7            3529        3772     1959898+  83  Linux
/dev/hda8            3773        4623     6835626   83  Linux
/dev/hda9            4624        4866     1951866   83  Linux
/dev/hda10           4867        4998     1060258+  83  Linux
------------------

/sbin/tune2fs -j /dev/hda6
tune2fs 1.38 (30-Jun-2005)
/sbin/tune2fs: Bad magic number in super-block while trying to open 
/dev/hda6
Couldn't find valid filesystem superblock.
-----------
gparted reports filesystem unknown

Unable to detect filesystem: Possible reasons
-- The filesystem is damaged
-- The filesystem is unknown to libparted
-- There is no filesystem avaiable (unformatted)
-------------

/sbin/e2fsck /dev/hda6
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/hda6

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>

 /sbin/e2fsck -b 8193 /dev/hda6
e2fsck 1.38 (30-Jun-2005)
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/hda6

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>

So something got damaged and can then the data still be salvaged?

Regards

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Lost HD Partition

[chuck gelm]

Hi, Peter:

 It looks like your partition is corrupted.
Although I would like to see if either of these two items would work.

#mount -t auto /dev/hda6 /usr/local

 -or-

comment out the line of fstab that specifies /dev/hda6 and
#mount /dev/hda6 /usr/local


 However, if you are sure that the partition was formated as
ext2 or ext3 before, this will not work as (I think) both filesystems
depend on the superblock.

:-|  Chuck
man mount
<snip>
-t vfstype

 The argument following the -t is used to indicate the file  system  type.
 The file system types which are currently supported include:
  adfs, affs, autofs, coda, coherent, cramfs, devpts, efs,  ext,  ext2, 
ext3,
  hfs, hpfs, iso9660, jfs, minix, msdos, ncpfs, nfs, ntfs, proc, qnx4, rmfs,
  reiserfs, romfs, smbfs, sysv, tmpfs, udf, ufs, umsdos, usbfs, vfat, xenix,
  xfs, xiafs.

 Note that coherent, sysv and xenix are equivalent and that xenix and  
coherent
 will be removed at some point in the future -- use sysv instead. Since 
kernel
 version 2.1.21 the types ext and xiafs do not exist anymore. Earlier, usbfs
 was known as usbdevfs.

 For most types all the mount program has to do is issue a simple mount(2)
 system call, and no detailed knowledge of the filesystem type is required.
 For a few types however (like nfs, smbfs, ncpfs)  ad  hoc  code is 
necessary.
 The nfs ad hoc code is built in, but smbfs and ncpfs have a separate mount
 program. In  order to  make  it possible to treat all types in a 
uniform way,
 mount will execute the program /sbin/mount.TYPE (if that exists) when 
called
 with type TYPE.  Since various versions of the smbmount program have 
different
 calling conventions, /sbin/mount.smbfs may have to be a shell script 
that sets
 up the desired call.
<snip>

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Lost HD Partition

[Hal MacArgle]

On 06-21, Peter wrote:
> 
> /sbin/e2fsck /dev/hda6
> e2fsck 1.38 (30-Jun-2005)
> Couldn't find ext2 superblock, trying backup blocks...
> /sbin/e2fsck: Bad magic number in super-block while trying to open /dev/hda6
> 
> 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>
> 
> /sbin/e2fsck -b 8193 /dev/hda6
> e2fsck 1.38 (30-Jun-2005)
> /sbin/e2fsck: Bad magic number in super-block while trying to open /dev/hda6
> 
> 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>

	IIRC, with the usual disclaimers, if the original fs was
created with 4K blocks the superblock would be: -b 32768.. The -b
8193 is for 1K block fs's... I hope that's right.. Also, IIRC, a fs
should not be checked if it's mounted which, in this case, it might
be but you don't know it.. I hope I'm not talking thru my hat.. <g>

-- 

    Hal - in Terra Alta, WV/US - Slackware GNU/Linux 10.1   (2.4.29)
.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs