Hi list
this is actually a problem on a debian system but I thought you might
be interested to hear of it and perhaps can offer some help.
I have a woody box (dell pe750, dual cpu) running a kernel from
backports.org (debian 'testing' packages built on a 'stable' box).
The kernel version is 2.6.7-1.backports.org.1.
This host is hooked up to an Apple Xserve RAID with a 2.3Tbyte ptn
that was created by the same system that is now giving trouble.
My problem is that mount (2.12-4.backports.org.1) fails to mount this
partition. It worked fine before, but stopped working after a power
outage. Before I was using mount version 2.11n-7woody1 (the stock debian
'woody' version). I upgraded to the backports.org version of mount after
this problem appeared, but it didn't help.
The symptom is -
# mount /dev/sdb1
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
or too many mounted file systems
(aren't you trying to mount an extended partition,
instead of some logical partition inside?)
My question to you is: where to look for help, if not here.
Do I need to upgrade mount? fdisk?
Am I missing a kernel module? I did a grep through the kernel-doc-2.6.7
tree for EFI and GPT and didn't find much information relevant to this
problem.
Thanks
Vince
More information
----------------
The filesystem is ext3 but I don't have a note of the command used to
create it. I do have the ext3 module loaded.
This filesystem is just data, it's not a booting issue.
In fact I've commented the fstab entry out so I can get a clean
boot, and am now trying to mount the fs on a fully running system.
I uncommented the entry after boot.
The fstab entry looks like this
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/sdb1 /export/archive01 ext3 defaults 0 2
To get this large a partition, I was forced to partition with a
self-built parted (1.6.19, which supports using a gpt disk label).
This worked ok, and parted still seems happy with the partition:
# /local/sbin/parted /dev/sdb print
Disk geometry for /dev/sdb: 0.000-2289288.000 megabytes
Disk label type: gpt
Minor Start End Filesystem Name Flags
1 0.017 2289287.983 ext3
Information: Don't forget to update /etc/fstab, if necessary.
Fdisk is not entirely happy however. (util-linux, 2.12-4.backports.org)
# fdisk -l /dev/sdb
You must set cylinders.
You can do this from the extra functions menu.
Disk /dev/sdb: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 267350 2147483647+ ee EFI GPT
Partition 1 has different physical/logical beginnings (non-Linux?):
phys=(0, 0, 1) logical=(0, 0, 2)
Partition 1 has different physical/logical endings:
phys=(1023, 254, 63) logical=(267349, 89, 4)
Nor is e2fsprogs (1.35-5.backports.org.1)
# e2fsck /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, 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>
Trying e2fsck -b 8193 /dev/sdb1 gives the same result.
# tune2fs -l /dev/sdb1
tune2fs 1.35 (28-Feb-2004)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
I tried turning on EFI_PARTITION in the kernel and rebuilding.
This doesn't help, the kernel just wedges itself during the boot,
shortly after starting kjournald and mounting the ext3 partitions on
the boot disk, /dev/sda (a 73GB scsi disk).
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
