unable to mount disks

Latest response

Hi,

I am on a RHEL6.8 box with three disks:
sda - CentOS6.8
sdb (xfs, 2TB)
sdc (xfs, 2TB)

After logging in, I try to mount sdb1 and sdc1 but get this error:

mount -t xfs /dev/sdb1 /scratch1

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

Anyone have a workaround for this?

thank you,
Karimi

KI
Log in to join the conversation

Responses

MK Guru 1972 points
18 October 2017 5:48 PM

First, the error message already includes a suggestion of what to do. What is the output of this command?

dmesg | tail

Remember that partitioning is required only on the system disk: any other disks can be used without partitioning if you don't have any requirement to split them into smaller units. So, first see if the sdb disk has any partitions in the first place:

grep sdb1 /proc/partitions

If there is no output, then the sdb disk has no partitions. If the disk already contains a filesystem, you can mount it with:

mount -t xfs /dev/sdb /scratch1

i.e. not /dev/sdb1 but just /dev/sdb.

KI Community Member 30 points
19 October 2017 7:37 PM

Hi Matti,

Thank you for the tips, here is some feedback:

dmesg | tail

XFS (sdb1): bad version XFS (sdb1): SB validate failed XFS (sdb1): bad version XFS (sdb1): SB validate failed XFS (sdb): bad magic number XFS (sdb): SB validate failed XFS (sdc): bad magic number XFS (sdc): SB validate failed XFS (sdb): bad magic number XFS (sdb): SB validate failed

grep sdb1 /proc/partitions

8 17 1953513472 sdb1

mount /dev/sdb /scratch1

mount: you must specify the filesystem type

mount -t xfs /dev/sdb /scratch1

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

I hope this gives some more insight.

thnx, Karimi

MK Guru 1972 points
20 October 2017 9:24 AM

OK, it looks like /dev/sdb is in fact partitioned, and so /dev/sdb1 is the right device to use. But the messages from dmesg indicate that these filesystems may have been created with a newer version of XFS driver/tools, and the driver version in your CentOS/RHEL system (which one it is, really?) might be too old to make sense of it. And whatever the problem actually is, /dev/sdc1 seems to have it too.

Has this filesystem been created on this system, or some other system? What was the OS version used to create these filesystems?

To verify the filesystem version, please run these commands:

echo "version" | xfs_db /dev/sdb1

echo "version" | xfs_db /dev/sdc1

The output from those commands should be something similar to:

versionnum [0xb4a4+0xa] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT

The value after "versionnum" identifies the version of XFS used to create the filesystem. The line above is what a RHEL 6.9 system will output for a filesystem created using the RedHat xfsprogs-3.1.1-20.el6.x86_64.rpm.

To see what your installed XFS tools are capable of, first create a large sparse file, use it as a loopback device and initialize it as an empty XFS filesystem:

dd if=/dev/zero of=/var/tmp/sparse-xfs-test.img bs=1024k seek=10240 count=1
losetup /dev/loop0 /var/tmp/sparse-xfs-test.img
mkfs.xfs /dev/loop0

Now you can use the xfs_db command to see what your installed XFS tools are capable of creating:

echo version | xfs_db /dev/loop0

Is the output from this command the same as from the /dev/sdb1 and /dev/sdc1 filesystems, or is it different?

Finally, let's clean up the remains of our experiment:

losetup -d /dev/loop0
rm /var/tmp/sparse-xfs-test.img
KI Community Member 30 points
20 October 2017 4:08 PM

Hi Matti,

My system is a CentOS6.8

The OS disk, /dev/sda was installed afresh. I expected that it would recognize existing disks /dev/sdb and /dev/sdc. Before, I had CentOS7.4, it was able to see the other disk without a problem.

Here is feedback from some of the commands:

echo "version" | xfs_db /dev/sdb1 xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided. cache_node_purge: refcount was 1, not zero (node=0x1291210) xfs_db: cannot read root inode (117) cache_node_purge: refcount was 1, not zero (node=0x1291810) xfs_db: cannot read realtime bitmap inode (117) xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided. xfs_db> version versionnum [0xb4b5+0x18a] =

echo "version" | xfs_db /dev/sdc1 xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided. cache_node_purge: refcount was 1, not zero (node=0x19e3210) xfs_db: cannot read root inode (117) cache_node_purge: refcount was 1, not zero (node=0x19e3810) xfs_db: cannot read realtime bitmap inode (117) xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided. xfs_db> version versionnum [0xb4b5+0x18a] =

The xfstools test went as shown above. echo version | xfs_db /dev/loop0 xfs_db> version versionnum [0xb4a4+0xa] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT

thank you, Karimi

MK Guru 1972 points
21 October 2017 3:52 AM

0xb4b5+0x18a is greater than 0xb4a4+0xa, so from that and the error messages from the xfs_db commands, it looks like the XFS filesystem on your sdb1 and sdc1 disks is definitely newer version than what the RHEL/CentOS 6.x XFS driver can handle.

Sorry, but it looks like you'll need to use CentOS 7.x to access those filesystems.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.